[musl] realloc buffer overflow issue

[musl] realloc buffer overflow issue

[Benedict]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

I found an memory leak issue in my multi-thread, which had fixed issue by the following patch



https://git.musl-libc.org/cgit/musl/commit/src/malloc?id=3e16313f8fe2ed143ae0267fd79d63014c24779f






about this patch, I think it involved a bug for realloc function: when the request size 'n' (the second paramter passed to realloc) lesser than the original memory size 'n0' (the memory block that first paramter of realloc pointed to) and the next chunk of  'self ' is in used state, the realloc should call trim(self, n) to split current chunk rather than call malloc, that will cause memcpy buffer overflow due to 'n < n0', and it will cause next malloc crash...


after fix, I think it should be like:
lock(mal.split_merge_lock);


size_t nsize = next->csize & C_INUSE ? 0 : CHUNK_SIZE(next);
if (nsize)) {
int i = bin_index(nsize);
lock_bin(i);
if (!(next->csize & C_INUSE)) {
unbin(next, i);
next = NEXT_CHUNK(next);
self->csize = next->psize = n0+nsize | C_INUSE;
}
unlock_bin(i);
}
    
    if(CHUNK_SIZE(self) >= n) {
        trim(self, n);
        unlock(mal.split_merge_lock);
return CHUNK_TO_MEM(self);
    }
unlock(mal.split_merge_lock);


copy_realloc:
/* As a last resort, allocate a new chunk and copy to it. */
new = malloc(n-OVERHEAD);
if (!new) return 0;
copy_free_ret:
memcpy(new, p, n0-OVERHEAD);
free(CHUNK_TO_MEM(self));
return new;




Benedict

[-- Attachment #2: Type: text/html, Size: 8992 bytes --]

Re: [musl] realloc buffer overflow issue

[Rich Felker]

On Sun, Feb 28, 2021 at 11:54:58PM +0800, Benedict wrote:
> I found an memory leak issue in my multi-thread, which had fixed issue by the following patch
> 
> 
> 
> https://git.musl-libc.org/cgit/musl/commit/src/malloc?id=3e16313f8fe2ed143ae0267fd79d63014c24779f
> 
> 
> 
> 
> 
> 
> about this patch, I think it involved a bug for realloc function:
> when the request size 'n' (the second paramter passed to realloc)
> lesser than the original memory size 'n0' (the memory block that
> first paramter of realloc pointed to) and the next chunk of 'self '
> is in used state, the realloc should call trim(self, n) to split
> current chunk rather than call malloc, that will cause memcpy buffer
> overflow due to 'n < n0', and it will cause next malloc crash...
> 
> 
> after fix, I think it should be like:
> lock(mal.split_merge_lock);
> 
> 
> size_t nsize = next->csize & C_INUSE ? 0 : CHUNK_SIZE(next);
> if (nsize)) {
> int i = bin_index(nsize);
> lock_bin(i);
> if (!(next->csize & C_INUSE)) {
> unbin(next, i);
> next = NEXT_CHUNK(next);
> self->csize = next->psize = n0+nsize | C_INUSE;
> }
> unlock_bin(i);
> }
>     
>     if(CHUNK_SIZE(self) >= n) {
>         trim(self, n);
>         unlock(mal.split_merge_lock);
> return CHUNK_TO_MEM(self);
>     }
> unlock(mal.split_merge_lock);
> 
> 
> copy_realloc:
> /* As a last resort, allocate a new chunk and copy to it. */
> new = malloc(n-OVERHEAD);
> if (!new) return 0;
> copy_free_ret:
> memcpy(new, p, n0-OVERHEAD);
> free(CHUNK_TO_MEM(self));
> return new;

I haven't looked in detail yet but isn't this the same bug fixed a
week after it was introduced with commits
cb5babdc8d624a3e3e7bea0b4e28a677a2f2fc46 and
fca7428c096066482d8c3f52450810288e27515c ?

Rich