[PATCH] malloc: Improve tcache double-free detection

Ben Kallus benjamin.p.kallus.gr@dartmouth.edu
Wed Mar 5 16:49:55 GMT 2025


HI Wilco,

> So I don't believe this patch actually improves "double free detection" - there is
only one tcache_key per process, ie. a double free in a different
thread will simply
write the same key again to the same location.

The patch doesn't detect the double-free at the time of the second
free; only at the time of the second malloc.

For example, suppose that thread 1 and thread 2 both free allocation
A, so it ends up in both threads' tcaches.
Then, thread 1 mallocs, and the allocator returns A and overwrites A's
key with 0.
When thread 2 mallocs, and the allocator would normally return A, it
instead detects that A's key has been changed to 0, and crashes.

This is what I mean by "double free detection."

> I don't believe pointer swizzling can be so easily defeated - you need to not just
leak a pointer, you need the ability to overwrite a pointer with one
that is swizzled
in a way that is useful to the attacker. When one is able to use
gadgets that swizzle
pointers you have already lost...

You only need gadgets if you're making a 1-stage exploit. In a
multi-stage exploit, you have the program leak the heap address to
you, then you compute the swizzled value and use it in the second
stage for the UAF.

As for the performance arguments, I won't dispute the numbers. Thank
you for running those ARM benchmarks.

-Ben


More information about the Libc-alpha mailing list