This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Check for large bin list corruption when inserting unsorted chunk
- From: DJ Delorie <dj at redhat dot com>
- To: Adam Maris <amaris at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 21 Feb 2019 20:30:52 -0500
- Subject: Re: [PATCH] malloc: Check for large bin list corruption when inserting unsorted chunk
Adam Maris <amaris@redhat.com> writes:
> {
> victim->fd_nextsize = fwd;
> victim->bk_nextsize = fwd->bk_nextsize;
> + if (__glibc_unlikely (fwd->bk_nextsize->fd_nextsize != fwd))
> + malloc_printerr ("malloc(): largebin double linked list corrupted (nextsize)");
At this point, the size of the chunk matches neither the previous nor
next chunks; we're creating a new "unique size" sub-head. So, both fd
and fd_nextsize should point to the next (fwd) chunk. We've hooked in
our new chunk but haven't yet fixed up the existing chunks, so this test
verifies that the links between the next chunk (fwd, which is a
start-of-size chunk) and the previous start-of-size chunk are still
cyclic. Ok.
> fwd->bk_nextsize = victim;
> victim->bk_nextsize->fd_nextsize = victim;
> }
> bck = fwd->bk;
> + if (bck->fd != fwd)
> + malloc_printerr ("malloc(): largebin double linked list corrupted (bk)");
At this point the newly inserted chunk may be a start-of-size chunk, or
a second-in-size chunk; either way, we've not yet linked it into the
fd-bk chain, so we can verify that the fwd->bk->fd is still cyclic. Ok.
So, looks correct to me.
Reviewed-by: DJ Delorie <dj@redhat.com>