[PATCH] malloc: Make sure tcache_key is not 0
Florian Weimer
fweimer@redhat.com
Wed Jul 30 08:29:14 GMT 2025
* Samuel Thibault:
> Florian Weimer, le mer. 30 juil. 2025 07:15:21 +0200, a ecrit:
>> * Samuel Thibault:
>>
>> > Othersize even if tcache_double_free_verify sets e->key to 0 before
>> > calling __libc_free, it gets called again by __libc_free, thus looping
>> > indefinitely.
>> >
>> > Fixes: c968fe50628db74b52124d863cd828225a1d305c ("malloc: Use tailcalls in __libc_free")
>> > ---
>> > malloc/malloc.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/malloc/malloc.c b/malloc/malloc.c
>> > index 5ca390cc22..970717eb28 100644
>> > --- a/malloc/malloc.c
>> > +++ b/malloc/malloc.c
>> > @@ -3152,6 +3152,9 @@ tcache_key_initialize (void)
>> > if (__getrandom_nocancel_nostatus_direct (&tcache_key, sizeof(tcache_key),
>> > GRND_NONBLOCK)
>> > != sizeof (tcache_key))
>> > + tcache_key = 0;
>> > +
>> > + while (tcache_key == 0)
>> > {
>> > tcache_key = random_bits ();
>> > #if __WORDSIZE == 64
>>
>> Do you have a test case that triggers the bug?
>
> It'd require e.g. ln -sf zero /dev/random, can we do that somehow with
> e.g. unshare?
Yes, we can do that. But malloc does not use /dev/{u,}random if
getrandom is available.
Is the issue that tcache_key == 0 is wrong from an algorithmic point of
view?
Thanks,
Florian
More information about the Libc-alpha
mailing list