[suggestion] tcache double-free check

[Carlos O'Donell]

On 7/23/20 8:06 AM, Florian Weimer wrote:
> * 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.)

I'm OK with that.

-- 
Cheers,
Carlos.