Re: [suggestion] tcache double-free check

[Carlos O'Donell <carlos@redhat.com>]

On 7/19/20 2:40 AM, Eyal Itkin via Libc-alpha wrote:
> Hello,
> 
> Going over the internals of the tcache entries, I stumbled upon the
> entry->key field used for double-free checks. The full thread behind
> this field can be found here:
> http://sourceware-org.1504.n7.nabble.com/patch-tcache-double-free-check-td544878.html.

Just for reference the ML list URL is here:
https://sourceware.org/pipermail/libc-alpha/2018-November/098357.html

> While the double-free check is a good idea, I think that Florian was
> correct when he asked about the reason behind storing pointers to the
> tcache control block on the heap itself. In the current
> implementation, free()ed tcache allocations will contain a pointer to
> the tcache control block, thus exposing it to corruption in case the
> programmer mistakenly used the allocation after it was freed / freed
> some buffers in the wrong way.
> 
> The reason behind using "tcache" as the entry key was explained by
> Delorie (the developer of this patch):
> "
> ... The value is arbitrary, it can be anything that we can argue won't
> come up in usual program flows.
> "

Correct.

> Instead of using some arbitrary constant or coming up with a fancy
> random value, is it possible we update the key to something that won't
> point to a critical memory management struct such as the tcache
> control block? I suggest a simple change that will ensure that the
> value used won't be a pointer that can be dereferenced: ~tcache
> (instead of tcache). The bitwise not costs a mere 1 CPU cycle, while
> making sure the key won't be a valid memory address.

That sounds good to me.

I assume the point being that you can't use a "memory derefernce"
gadget directly with that memory, you'd need some other primitive
to process the ~tcache.

> Before submitting a patch for this change, I wanted to hear your
> opinion about it.
> Thanks, and credit to Awarau for pointing this out to me.
> Eyal.

I have no objections. I'd like to hear Florian's input (on TO).

-- 
Cheers,
Carlos.