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

[p0l42]

Hello,
I found a heap buffer overflow in ok_wav.c: ok_wav_decode_ms_ima_adpcm_data, line 627.
In detail, my testcase's input size < 4, but in line 627, the for loop access input[2] and input[3], so here is a accessing out of range.
The AddressSanitizer report is as follows:
`=================================================================
==7463==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000038 at pc 0x55b19c358318 bp 0x7ffd9c5cc8d0 sp 0x7ffd9c5cc8c0
READ of size 1 at 0x602000000038 thread T0
#0 0x55b19c358317 in ok_wav_decode_ms_ima_adpcm_data ok_wav.c:627
#1 0x55b19c35a4f5 in ok_wav_decode_data ok_wav.c:893
#2 0x55b19c35b3f7 in ok_wav_decode_wav_file ok_wav.c:1017
#3 0x55b19c35c6bd in ok_wav_decode ok_wav.c:1181
#4 0x55b19c354b43 in ok_wav_read_with_allocator ok_wav.c:169
#5 0x55b19c3549a4 in ok_wav_read ok_wav.c:158
#6 0x55b19c35c983 in main wav.c:5
#7 0x7fba9c757082 in __libc_start_main ../csu/libc-start.c:308
#8 0x55b19c35440d in _start (/home/yurenjin/wavana/wavvuln+0x240d)

0x602000000038 is located 0 bytes to the right of 8-byte region [0x602000000030,0x602000000038)
allocated by thread T0 here:
#0 0x7fba9ca32808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x55b19c3546d7 in ok_stdlib_alloc ok_wav.c:93
#2 0x55b19c357e47 in ok_wav_decode_ms_ima_adpcm_data ok_wav.c:587
#3 0x55b19c35a4f5 in ok_wav_decode_data ok_wav.c:893
#4 0x55b19c35b3f7 in ok_wav_decode_wav_file ok_wav.c:1017
#5 0x55b19c35c6bd in ok_wav_decode ok_wav.c:1181
#6 0x55b19c354b43 in ok_wav_read_with_allocator ok_wav.c:169
#7 0x55b19c3549a4 in ok_wav_read ok_wav.c:158
#8 0x55b19c35c983 in main wav.c:5
#9 0x7fba9c757082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow ok_wav.c:627 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 00[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
==7463==ABORTING`
The testcase trigger this I'll upload to my github soon.

[p0l42]

The testcase is here
line626.zip