A heap-buffer-overflow detected in ok_wav.c:613

[p0l42]

Hello, I found a heap buffer overflow in ok_wav.c: ok_wav_decode_ms_ima_adpcm_data, line 613. In detail, my testcase's input size is 2, but in line 613, the code access input[2], so here is a accessing out of range. The AddressSanitizer report is as follows: `================================================================= ==2819==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000032 at pc 0x561bab18f205 bp 0x7ffe9b880ec0 sp 0x7ffe9b880eb0 READ of size 1 at 0x602000000032 thread T0 #0 0x561bab18f204 in ok_wav_decode_ms_ima_adpcm_data (a.out+0x6204) #1 0x561bab191550 in ok_wav_decode_data (a.out+0x8550) #2 0x561bab192452 in ok_wav_decode_wav_file (a.out+0x9452) #3 0x561bab193718 in ok_wav_decode (a.out+0xa718) #4 0x561bab18bb43 in ok_wav_read_with_allocator (a.out+0x2b43) #5 0x561bab18b9a4 in ok_wav_read (a.out+0x29a4) #6 0x561bab1939de in main (a.out+0xa9de) #7 0x7f719902e082 in __libc_start_main ../csu/libc-start.c:308 #8 0x561bab18b40d in _start (a.out+0x240d)

0x602000000032 is located 0 bytes to the right of 2-byte region [0x602000000030,0x602000000032) allocated by thread T0 here: #0 0x7f7199309808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 #1 0x561bab18b6d7 in ok_stdlib_alloc (a.out+0x26d7) #2 0x561bab18ee47 in ok_wav_decode_ms_ima_adpcm_data (a.out+0x5e47) #3 0x561bab191550 in ok_wav_decode_data (a.out+0x8550) #4 0x561bab192452 in ok_wav_decode_wav_file (a.out+0x9452) #5 0x561bab193718 in ok_wav_decode (a.out+0xa718) #6 0x561bab18bb43 in ok_wav_read_with_allocator (a.out+0x2b43) #7 0x561bab18b9a4 in ok_wav_read (a.out+0x29a4) #8 0x561bab1939de in main (a.out+0xa9de) #9 0x7f719902e082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow (a.out+0x6204) in ok_wav_decode_ms_ima_adpcm_data Shadow bytes around the buggy address: 0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c047fff8000: fa fa 00 fa fa fa[02]fa fa fa fa fa fa fa fa fa 0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8050: 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 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 ==2819==ABORTING` The testcase trigger this I'll upload to my github soon.

[p0l42]

The testcase is here line613.zip