stack-buffer-overflow bug in src/xml_string.c:100:8 xml_strcat

[fceval]

More detail is depicted in bug detail

xml file : runinfosqlites/simple_xml/fca/1/crashes/4ec6278ef2903cfd0a07c806495846fd59044943919b3e536e60de02b9d5059d

Memory in xml stack total : 157 blocks : 1

==2295070==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffd55bc260 at pc 0x0000004c5392 bp 0x7fffd55bb820 sp 0x7fffd55bb818 WRITE of size 1 at 0x7fffd55bc260 thread T0 #0 0x4c5391 in xml_strcat /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml_string.c:100:8 #1 0x4cdd0f in xmlelement_makeheadstr /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml_element.c:746:5 #2 0x4c3e67 in xml_saveelement /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml.c:181:9 #3 0x4c3caf in xml_save /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml.c:167:2 #4 0x4c21d5 in xml_example_run /magma/targets/simple_xml/repo/examples/build/make/../../xml_test.c:63:5 #5 0x4c2644 in xml_example /magma/targets/simple_xml/repo/examples/build/make/../../xml_test.c:85:5 #6 0x4c20fe in main /magma/targets/simple_xml/repo/examples/build/make/../../main.c:13:12 #7 0x7fd3d3fdb082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #8 0x41ab09 in _start (benchmarks/asan/simple_xml+0x41ab09)

Address 0x7fffd55bc260 is located in stack of thread T0 at offset 1056 in frame #0 0x4c3d0f in xml_saveelement /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml.c:176

This frame has 1 object(s): [32, 1056) 'buffer' (line 177) <== Memory access at offset 1056 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions are supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /magma/targets/simple_xml/repo/examples/build/make/../../../src/xml_string.c:100:8 in xml_strcat Shadow bytes around the buggy address: 0x10007aaaf7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10007aaaf840: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3 0x10007aaaf850: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 0x10007aaaf860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10007aaaf890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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 ==2295070==ABORTING

[xfwangqiang]

Thank you for your feedback. This is indeed an issue — the root cause is that the content of the XML element exceeds 1KB. The initial design only considered our own application scenarios, and we also found that a large amount of stack memory is used. In RTOS environments, the stack memory capacity is generally set relatively small initially, which can easily lead to thread issues. We will fix this problem in the next version and adopt dynamic memory allocation to resolve the aforementioned issues.