Created attachment 86 [details] reproducer SHA1 for the reproducer: 246b396d0b921805e747ea44c03632166a92672d Credit: Henri Salo from Nixu Corporation 00000000 52 49 46 46 30 00 00 00 30 30 30 30 52 49 46 46 |RIFF0...0000RIFF| 00000010 10 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30 |....000000000000| 00000020 30 30 30 30 61 30 30 30 30 |0000a0000| 00000029 ./bin/rifftree libgig-rifftree-heap-buffer-overflow-001.riff RIFF(0000)-> ================================================================= ==2505==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60700000df20 at pc 0x7ff68f0ade14 bp 0x7ffe7de62f60 sp 0x7ffe7de62f58 READ of size 4 at 0x60700000df20 thread T0 #0 0x7ff68f0ade13 in RIFF::List::GetListTypeString() const /src/libgig/src/RIFF.cpp:1536 #1 0x403ff3 in PrintChunkList(RIFF::List*, bool) /src/libgig/src/tools/rifftree.cpp:155 #2 0x402998 in main /src/libgig/src/tools/rifftree.cpp:127 #3 0x7ff68e29cb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) #4 0x4036b9 (/builds/libgig/2017-10-16/bin/rifftree+0x4036b9) 0x60700000df20 is located 0 bytes to the right of 80-byte region [0x60700000ded0,0x60700000df20) allocated by thread T0 here: #0 0x7ff68f4dbfff in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x54fff) #1 0x7ff68f0b9e37 in RIFF::List::LoadSubChunks(RIFF::progress_t*) /src/libgig/src/RIFF.cpp:1451 #2 0x7ff68f0bb6f6 in RIFF::List::GetFirstSubChunk() /src/libgig/src/RIFF.cpp:1120 #3 0x403a13 in PrintChunkList(RIFF::List*, bool) /src/libgig/src/tools/rifftree.cpp:143 #4 0x402998 in main /src/libgig/src/tools/rifftree.cpp:127 #5 0x7ff68e29cb44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44) SUMMARY: AddressSanitizer: heap-buffer-overflow /src/libgig/src/RIFF.cpp:1536 RIFF::List::GetListTypeString() const Shadow bytes around the buggy address: 0x0c0e7fff9b90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00 0x0c0e7fff9bd0: 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 =>0x0c0e7fff9be0: 00 00 00 00[fa]fa fa fa 00 00 00 00 00 00 00 00 0x0c0e7fff9bf0: 06 fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa 0x0c0e7fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c0e7fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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 Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==2505==ABORTING
This issue might also be in the library, but needs proper analysis.
Since I guess this report seems to be based on specially crafted fuzzy input data, please provide an appropriate patch to fix this issue, otherwise this report will be closed (due to the same reason as described in bug #306).