[suggestion] tcache double-free check

[Florian Weimer]

* Adhemerval Zanella via Libc-alpha:

> 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.

For a one-time initialization, we could call getrandom directly.  (And
hope that seccomp filters do not terminate the process.)

Thanks,
Florian