READ unknown address in dwg_encode_add_object in encode.c:3877

[giantbranch]

Affected version

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

What's the problem?

Segmentation fault in dwg_encode_add_object in encode.c:3877 because of reading unknown address.

ASAN report:

$ ./dwgrewrite ./pocs/tests_64229
......
......
......
==2884155==ERROR: AddressSanitizer: SEGV on unknown address 0x7fffe435c89f (pc 0x0000004ab9e0 bp 0x7fffffffc360 sp 0x7fffffffbb10 T0)
==2884155==The signal is caused by a READ memory access.
    #0 0x4ab9e0 in __sanitizer::internal_memmove(void*, void const*, unsigned long) /src/llvm-project-12.0.0.src/compiler-rt/lib/sanitizer_common/sanitizer_libc.cpp:68:16
    #1 0x497605 in __asan_memmove /src/llvm-project-12.0.0.src/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3
    #2 0xfe6ba3 in memmove /usr/include/x86_64-linux-gnu/bits/string_fortified.h:40:10
    #3 0xfe6ba3 in dwg_encode_add_object /src/libredwg/src/encode.c:3877:11
    #4 0xf98c78 in dwg_encode /src/libredwg/src/encode.c:2352:16
    #5 0x4cbcf6 in dwg_write_file /src/libredwg/src/dwg.c:429:11
    #6 0x4c939f in main /src/libredwg/programs/dwgrewrite.c:349:11
    #7 0x7ffff7c580b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16
    #8 0x41c3fd in _start (/mnt/disk/out/libredwg/programs_asan/dwgrewrite+0x41c3fd)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /src/llvm-project-12.0.0.src/compiler-rt/lib/sanitizer_common/sanitizer_libc.cpp:68:16 in __sanitizer::internal_memmove(void*, void const*, unsigned long)
==2884155==ABORTING

Compile command

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

How can we reproduce the issue?

unzip tests_64229.zip
dwgrewrite ./tests_64229

POC file :

tests_64229.zip

[giantbranch]

Compare with #356 , according to the stack， It my be different manifestations caused by the same root cause.

[rurban]

Still heap-use-after-free as in #497 and #356, but the original error is fixed

[rurban]

Now with commit 69dcecd2157b467ddffb94c0d01b6d6e0c1b3b62 all those issues fixed