[suggestion] tcache double-free check

[Adhemerval Zanella]

On 22/07/2020 23:35, Carlos O'Donell via Libc-alpha wrote:
> On 7/21/20 2:03 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>>> 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.
>>
>> Why can't we use a random marker value?  Then we don't leak an address,
>> either.
> 
> I'm not against it, but we'd need something that is random, and for that
> we need entropy. What have we got to use?

We have include/random-bits.h which get some entropy from the clock
(and shuffle the bits to avoid some clock bias). It is far from perfect,
but it is used internally on some specific cases.

Another possibility if a more robust random source is requires would be
to try work on the arc4random patch proposal from Florian.