Re: [PATCH] malloc: Check for large bin list corruption when inserting unsorted chunk

[Florian Weimer <fweimer@redhat.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