[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