[PATCH v2 0/2] malloc: introduce ifuncs for malloc functions
Florian Weimer
fweimer@redhat.com
Thu May 7 07:22:33 GMT 2026
* Wilco Dijkstra:
> Hi Florian,
>
>> I looked at this recently and it's rather desirable to tag chunks added
>> to tcache so that they can be returned directly from a future malloc
>> call. This means that memory tagging cannot be implemented as a pure
>> wrapper.
>
> That's QoI. The existing implementation always untags and retags in tcache -
> this allows detection of use after free (or double free) and using the chunk
> for internal data.
User after free detection is slightly *more* reliable if you directly
switch to the next random tag (different from the current tag) during
free. If free switches to the metadata tag and malloc tags memory with
a random tag, 1 in 16 malloc-free-malloc cycles does not change the tag.
> You could retag only on free and not on malloc, but having chunk structs
> that overlap user data makes all this tricky unfortunately. The tcache code
> could in principle not use internal data or we could retag only the size of
> the chunk struct.
Even with an implicit tag verification architecture, I don't see how
user-tagged chunks in tcache cause problems. The pointer comparisons in
the main allocator are problematic if the tags don't match as expected,
but I don't think that exists in tcache.
Thanks,
Florian
More information about the Libc-alpha
mailing list