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

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2850 bytes --]


On 6/12/26 2:13 AM, Vlastimil Babka (SUSE) wrote:
> 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.

Okay, it wasn't clear in the cover letter but now assuming the same...

> Accesses (UAF) perhaps may not happen by that owner, or if they happen after
> he object is reallocated, they are not recognized as such.

Right.

User A				User B
=======================================================================
allocates an object
frees the object
				allocates the object
frees the object again
(poison the object)
				overwrites the object
				(not detected until freed)
				frees the object, UAF detected!

By the time it detects a UAF, free trace is from user A (of the second
free) (since we perform consistency checks before updating free trace),
alloc trace is from user B.

So the only thing we know about user A is the stack trace of double free
but no original alloc/free traces of user A.

>> 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.

Right.

>> 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.

Right.

> 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.

Right and not all users reporting bugs are willying to do that...

-- 
Cheers,
Harry / Hyeonggon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]