Re: [RFC PATCH 0/5] mm/slub: preserve previous object lifetime

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/11/26 09:19, Harry Yoo wrote:
> Hi Pengpeng,
> 
> On 6/11/26 3:39 PM, Pengpeng Hou wrote:
>> SLAB_STORE_USER currently stores one allocation track and one free track
>> for an object. This is useful, but it loses part of the previous lifetime
>> when the object is reused: the new allocation overwrites the allocation
>> track, and a later stale free can overwrite the free track.
> 
> I'm not sure what you meant by "stale free", UAF is accessing object
> that are freed. What makes the free "stale"?

I'm guessing it means 'second/duplicated free" of the previous owner.
Accesses (UAF) perhaps may not happen by that owner, or if they happen after
he object is reallocated, they are not recognized as such.

> In general, I don't think slab_debug=UP is the right tool to debug
> use-after-frees, because slab will never know _when_ the object was
> overwritten. It can only tell that somebody has overwritten freed
> objects by checking if the object content is POISON_FREE or POISON_END.

It could give more information about double frees like this, however.

> KASAN is a better tool to debug use-after-frees, because it can
> tell you which kernel code is accessing memory it shouldn't. (It also
> quarantines slab objects to avoid immediately reusing the object for
> better coverage).
> 
> So I have to ask, "Why not use KASAN instead?" before enhancing
> slab_debug (neither is intended for production anyway).

From my distro experience, it's very useful to tell a user to just enable
slub_debug for a specific cache with the existing kernel, with some but not
prohibitive overhead. And with some luck it gives you enough information to
find the root cause too. So in that sense it can be used in production.
KASAN is indeed superior wrt catching issues, but almost never applicable in
such environment. It would need a rebuilt kernel and the overhead is much
higher. So it's a tradeoff.

>> For free-after-reuse bugs, the report can therefore contain the victim
>> allocation and the stale free, while the earlier alloc/free pair that
>> explains where the stale pointer came from is no longer available.
> 
> Again, I'm confused. I have no idea what "free-after-reuse" means.
> Objects cannot be reused until they are not freed, no?