Re: [PATCH] mm/slab: sample slab_state once in kmem_cache_destroy()

[Harry Yoo <harry@kernel.org>]

Uh, apologies for the late reply.
Catching up after trip at LPC...

On Thu, Oct 01, 2026 at 05:42:36PM +0200, Imre Kaloz wrote:
> Hi Harry,
> 
> On Thu, 1 Oct 2026, Harry Yoo wrote:
> 
> > Hi Imre,
> > Thanks for catching and fixing this!
> > 
> > On Wed, Sep 30, 2026 at 09:51:09PM +0200, Imre Kaloz wrote:
> > > kmem_cache_destroy() tests slab_state >= FULL for sysfs_slab_unlink()
> > > and again in kmem_cache_release() for sysfs_slab_release(), with the
> > > cache already off slab_caches in between. If slab_late_init() runs in
> > > that gap it sets slab_state to FULL but never calls sysfs_slab_add() for
> > > the unlinked cache, so kmem_cache_release() ends up in kobject_put() on
> > > a kobject that was never initialized:
> > > 
> > >   WARNING: lib/kobject.c:734 at kobject_put+0x64/0x2c0, CPU#1: kworker/u8:3/55
> > >   kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put() is being called.
> > >   refcount_t: underflow; use-after-free.
> > >   kobject_put+0x64/0x2c0
> > >   sysfs_slab_release+0xc/0x20
> > >   kmem_cache_destroy+0x104/0x1e0
> > >   bioset_exit+0x13c/0x1e0
> > >   disk_release+0x54/0x140
> > >   put_disk+0x18/0x40
> > >   floppy_async_init+0xbec/0xd10
> > > 
> > > Seen on sparc64 at boot, where the asynchronous floppy init tears down
> > > its bio slab while the late initcalls are running.
> > > 
> > > Read slab_state once, under slab_mutex which slab_late_init() holds when
> > > it sets FULL, and use the result for both the unlink and the release.
> > > The kobject flags (state_initialized, state_in_sysfs) were considered as
> > > the key instead, but slab_state is what cache creation and
> > > slab_late_init() decide on.
> > > 
> > > debugfs_slab_release() is not part of the race: it only looks the cache
> > > up by name in the debugfs root and does nothing before that root exists.
> > > 
> > > Fixes: 4ec10268ed98 ("mm, slab: unlink slabinfo, sysfs and debugfs immediately")
> > 
> > Overall looks good to me, but could you please explain why it's
> > not relevant before this commit? pre-4ec10268 still reads slab_state
> > outside slab_mutex.
> > 
> 
> The outside-mutex read is older, yes. What 4ec10268ed98 changed is that
> unlink and release no longer share it.

Right.

> Before that commit, kmem_cache_release() did one test and used it for
> both:
> 
>     if (slab_state >= FULL) {
>         sysfs_slab_unlink(s);
>         sysfs_slab_release(s);
>     } else {
>         slab_kmem_cache_release(s);
>     }
> 
> So the two could not disagree.

Right.

> 4ec10268 moved sysfs_slab_unlink() into
> kmem_cache_destroy(), after list_del() and after dropping slab_mutex,
> and left a second slab_state test in kmem_cache_release() for
> sysfs_slab_release(). The cache is already off slab_caches in between.

Right.

> That is the window in the warning: the first test sees < FULL, so the
> kobject is never linked; slab_late_init() then sets FULL under
> slab_mutex and calls sysfs_slab_add() only for caches still on the
> list; the second test sees FULL and kobject_put()s a kobject that
> kobject_init() never ran on.
> 
> A single read cannot produce that split decision, which is why Fixes:
> points at 4ec10268ed98.

Right.

> There is a related older window: after list_del() and before that
> single read, slab_sysfs_init() could set FULL, skip this cache, and
> the single read would then call both unlink and release on an
> uninitialized kobject.

No, with this patch slab_sysfs_init() cannot set the state to FULL
because the slab_caches list and slab_state are protected by slab_mutex.

> I have not hit that, and this patch does not close it.

I think the patch does close two bugs.

One introduced by 4ec10268ed98 (reading slab_state twice),
another (reading slab_state outside slab_mutex) introduced by, hmm,
not sure which commit introduced it :) should be very old.

-- 
Cheers,
Harry / Hyeonggon