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: Florian Weimer <fweimer at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 06 Mar 2019 13:09:46 +0100
- Subject: Re: [PATCH] malloc: Check for large bin list corruption when inserting unsorted chunk
- References: <xnmumoa9tf.fsf@greed.delorie.com>
* DJ Delorie:
> 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>
I agree with this analysis.
Adam's submission is no longer covered by the Red Hat copyright
assignment, though, but I believe we can still accept it because it was
submitted under the assignment, and it is a small change anyway.
Thanks,
Florian