[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