The setup_malloc behaves differently when f->alloc.alloc_buffer is pre-allocated. Instead of returning NULL as in malloc case [4] it shifts the pre-allocated buffer by zero and returns the currently available memory block.
static void *setup_malloc(vorb *f, int sz)
{
sz = (sz+7) & ~7; // round up to nearest 8 for alignment of future allocs.
f->setup_memory_required += sz;
if (f->alloc.alloc_buffer) {
void *p = (char *) f->alloc.alloc_buffer + f->setup_offset; // [5]
if (f->setup_offset + sz > f->temp_offset) return NULL;
f->setup_offset += sz;
return p;
}
return sz ? malloc(sz) : NULL; // [4]
}
==93713==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f37941697ff at pc 0x0000004e41ed bp 0x7ffe67641670 sp 0x7ffe67641668
WRITE of size 1 at 0x7f37941697ff thread T0
#0 0x4e41ec in start_decoder(stb_vorbis*) tests/../stb_vorbis.c:3658:19
#1 0x4f9444 in stb_vorbis_open_memory tests/../stb_vorbis.c:5112:8
A crafted file may trigger out of bounds write in
f->vendor[len] = (char)'\0';
[1]. The root cause is that iflen
read instart_decoder
[2] is-1
andlen + 1
becomes0
when passed tosetup_malloc
in [3].The
setup_malloc
behaves differently whenf->alloc.alloc_buffer
is pre-allocated. Instead of returningNULL
as inmalloc
case [4] it shifts the pre-allocated buffer by zero and returns the currently available memory block.Impact
This issue may lead to code execution.
Resources
To reproduce the issue: