## Affected version 

the latest commit: https://github.com/LibreDWG/libredwg/tree/45d2a290c65ed691be0901ba2b2ef51044e07a16 and 0.12.4

## What's the problem?


A heap buffer overflow was discovered in dwg_dxf_SHAPE_private in dwg.spec.

ASAN report:

```
==2711==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000d70 at pc 0x000000ee5b42 bp 0x7fffffffcbd0 sp 0x7fffffffcbc8
READ of size 8 at 0x602000000d70 thread T0
    #0 0xee5b41 in dwg_dxf_SHAPE_private /src/libredwg/src/./dwg.spec:1675:40
    #1 0xea0f59 in dwg_dxf_SHAPE /src/libredwg/src/./dwg.spec:1642:1
    #2 0xe95ea0 in dwg_dxf_object /src/libredwg/src/out_dxf.c:2680:14
    #3 0xe6817c in dxf_entities_write /src/libredwg/src/out_dxf.c:3532:16
    #4 0xe41b4c in dwg_write_dxf /src/libredwg/src/out_dxf.c:3682:7
    #5 0x4c864b in main /src/libredwg/programs/dxfwrite.c:451:11
    #6 0x7ffff6ee383f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291
    #7 0x41bc98 in _start (/mnt/disk/out/libredwg/programs_asan/dxfwrite+0x41bc98)

0x602000000d71 is located 0 bytes to the right of 1-byte region [0x602000000d70,0x602000000d71)
allocated by thread T0 here:
    #0 0x49684d in malloc /src/llvm-project-12.0.0.src/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x4ded20 in bit_read_TV /src/libredwg/src/bits.c:1547:28
    #2 0x7b8edb in dwg_decode_MLINESTYLE_private /src/libredwg/src/./dwg.spec:3966:3
    #3 0x59d003 in dwg_decode_MLINESTYLE /src/libredwg/src/./dwg.spec:3962:1
    #4 0x5904de in dwg_decode_add_object /src/libredwg/src/decode.c:5821:15
    #5 0x4efe14 in decode_R13_R2000 /src/libredwg/src/decode.c:1342:19
    #6 0x4e77c1 in dwg_decode /src/libredwg/src/decode.c:246:36
    #7 0x4c9f9e in dwg_read_file /src/libredwg/src/dwg.c:254:11
    #8 0x4c8121 in main /src/libredwg/programs/dxfwrite.c:321:15
    #9 0x7ffff6ee383f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291

SUMMARY: AddressSanitizer: heap-buffer-overflow /src/libredwg/src/./dwg.spec:1675:40 in dwg_dxf_SHAPE_private
Shadow bytes around the buggy address:
  0x0c047fff8150: fa fa 00 02 fa fa 01 fa fa fa 00 fa fa fa 00 06
  0x0c047fff8160: fa fa 01 fa fa fa 01 fa fa fa 01 fa fa fa 01 fa
  0x0c047fff8170: fa fa 01 fa fa fa 07 fa fa fa 00 06 fa fa 00 04
  0x0c047fff8180: fa fa 01 fa fa fa 00 06 fa fa 01 fa fa fa 01 fa
  0x0c047fff8190: fa fa 01 fa fa fa 00 fa fa fa 00 02 fa fa 01 fa
=>0x0c047fff81a0: fa fa 00 06 fa fa 00 04 fa fa 04 fa fa fa[01]fa
  0x0c047fff81b0: fa fa 01 fa fa fa 01 fa fa fa 01 fa fa fa 07 fa
  0x0c047fff81c0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff81d0: fa fa 00 fa fa fa 00 fa fa fa 00 01 fa fa 00 01
  0x0c047fff81e0: fa fa 00 01 fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff81f0: fa fa 00 04 fa fa 00 01 fa fa 06 fa fa fa 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==2711==ABORTING
```


## Compile command

```
CC="clang" CFLAGS="-O1 -g -fsanitize=address" ./configure --enable-release --disable-shared && make
```

## How can we reproduce the issue?

```
unzip tests_64257.zip
dxfwrite -I DWG -o /dev/null -y ./tests_64257
```
POC file :  
[tests_64257.zip](https://github.com/LibreDWG/libredwg/files/6635509/tests_64257.zip)

Heap-buffer-overflow in dwg_dxf_SHAPE_private in dwg.spec
This is a GitHub Issue
repo:libredwg
owner:LibreDWG
Title : Heap-buffer-overflow in dwg_dxf_SHAPE_private in dwg.spec
Issue date:

--- start body ---
## Affected version 

the latest commit: https://github.com/LibreDWG/libredwg/tree/45d2a290c65ed691be0901ba2b2ef51044e07a16 and 0.12.4

## What's the problem?


A heap buffer overflow was discovered in dwg_dxf_SHAPE_private in dwg.spec.

ASAN report:

```
==2711==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000d70 at pc 0x000000ee5b42 bp 0x7fffffffcbd0 sp 0x7fffffffcbc8
READ of size 8 at 0x602000000d70 thread T0
    #0 0xee5b41 in dwg_dxf_SHAPE_private /src/libredwg/src/./dwg.spec:1675:40
    #1 0xea0f59 in dwg_dxf_SHAPE /src/libredwg/src/./dwg.spec:1642:1
    #2 0xe95ea0 in dwg_dxf_object /src/libredwg/src/out_dxf.c:2680:14
    #3 0xe6817c in dxf_entities_write /src/libredwg/src/out_dxf.c:3532:16
    #4 0xe41b4c in dwg_write_dxf /src/libredwg/src/out_dxf.c:3682:7
    #5 0x4c864b in main /src/libredwg/programs/dxfwrite.c:451:11
    #6 0x7ffff6ee383f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291
    #7 0x41bc98 in _start (/mnt/disk/out/libredwg/programs_asan/dxfwrite+0x41bc98)

0x602000000d71 is located 0 bytes to the right of 1-byte region [0x602000000d70,0x602000000d71)
allocated by thread T0 here:
    #0 0x49684d in malloc /src/llvm-project-12.0.0.src/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
    #1 0x4ded20 in bit_read_TV /src/libredwg/src/bits.c:1547:28
    #2 0x7b8edb in dwg_decode_MLINESTYLE_private /src/libredwg/src/./dwg.spec:3966:3
    #3 0x59d003 in dwg_decode_MLINESTYLE /src/libredwg/src/./dwg.spec:3962:1
    #4 0x5904de in dwg_decode_add_object /src/libredwg/src/decode.c:5821:15
    #5 0x4efe14 in decode_R13_R2000 /src/libredwg/src/decode.c:1342:19
    #6 0x4e77c1 in dwg_decode /src/libredwg/src/decode.c:246:36
    #7 0x4c9f9e in dwg_read_file /src/libredwg/src/dwg.c:254:11
    #8 0x4c8121 in main /src/libredwg/programs/dxfwrite.c:321:15
    #9 0x7ffff6ee383f in __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:291

SUMMARY: AddressSanitizer: heap-buffer-overflow /src/libredwg/src/./dwg.spec:1675:40 in dwg_dxf_SHAPE_private
Shadow bytes around the buggy address:
  0x0c047fff8150: fa fa 00 02 fa fa 01 fa fa fa 00 fa fa fa 00 06
  0x0c047fff8160: fa fa 01 fa fa fa 01 fa fa fa 01 fa fa fa 01 fa
  0x0c047fff8170: fa fa 01 fa fa fa 07 fa fa fa 00 06 fa fa 00 04
  0x0c047fff8180: fa fa 01 fa fa fa 00 06 fa fa 01 fa fa fa 01 fa
  0x0c047fff8190: fa fa 01 fa fa fa 00 fa fa fa 00 02 fa fa 01 fa
=>0x0c047fff81a0: fa fa 00 06 fa fa 00 04 fa fa 04 fa fa fa[01]fa
  0x0c047fff81b0: fa fa 01 fa fa fa 01 fa fa fa 01 fa fa fa 07 fa
  0x0c047fff81c0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff81d0: fa fa 00 fa fa fa 00 fa fa fa 00 01 fa fa 00 01
  0x0c047fff81e0: fa fa 00 01 fa fa 00 fa fa fa 00 fa fa fa 00 fa
  0x0c047fff81f0: fa fa 00 04 fa fa 00 01 fa fa 06 fa fa fa 00 fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==2711==ABORTING
```


## Compile command

```
CC="clang" CFLAGS="-O1 -g -fsanitize=address" ./configure --enable-release --disable-shared && make
```

## How can we reproduce the issue?

```
unzip tests_64257.zip
dxfwrite -I DWG -o /dev/null -y ./tests_64257
```
POC file :  
[tests_64257.zip](https://github.com/LibreDWG/libredwg/files/6635509/tests_64257.zip)

--- end body ---
