Re: [PATCH] mm/slub: Fix reference count leak in sysfs_slab_add

[Harry Yoo]

On Tue, May 19, 2026 at 01:47:20PM +0800, Guangshuo Li wrote:
> kobject_init_and_add() takes reference even when it fails. If this
> function returns an error in sysfs_slab_add(), kobject_put() should be
> called to properly clean up the memory associated with the object.

This was done intentionally by commit 2420baa8e046 ("mm/slab: Allow
cache creation to proceed even if sysfs registration fails"):
>  mm/slab: Allow cache creation to proceed even if sysfs registration fails
> 
>     When kobject_init_and_add() fails during cache creation,
>     kobj->name can be leaked because SLUB does not call kobject_put(),
>     which should be invoked per the kobject API documentation.
>     This has a bit of historical context, though; SLUB does not call
>     kobject_put() to avoid double-free for struct kmem_cache because
>     1) simply calling it would free all resources related to the cache, and
>     2) struct kmem_cache descriptor is always freed by cache_cache()'s
>     error handling path, causing struct kmem_cache to be freed twice.
> 
>     This issue can be reproduced by creating new slab caches while applying
>     failslab for kernfs_node_cache. This makes kobject_add_varg() succeed,
>     but causes kobject_add_internal() to fail in kobject_init_and_add()
>     during cache creation.
> 
>     Historically, this issue has attracted developers' attention several times.
>     Each time a fix addressed either the leak or the double-free,
>     it caused the other issue. Let's summarize a bit of history here:
> 
>       The leak has existed since the early days of SLUB.
> 
>       Commit 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
>       introduced a double-free bug while fixing the leak.
> 
>       Commit 80da026a8e5d ("mm/slub: fix slab double-free in case of duplicate
>       sysfs filename") re-introduced the leak while fixing the double-free
>       error.
> 
>       Commit dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()")
>       fixed the memory leak, but it was later reverted by commit 757fed1d0898
>       ("Revert "mm/slub: fix a memory leak in sysfs_slab_add()"") to avoid
>       the double-free error.
> 
>       This is where we are now: we've chosen a memory leak over a double-free.
> 
>     To resolve this memory leak, skip creating sysfs files if it fails
>     and continue with cache creation regardless (as suggested by Christoph).
>     This resolves the memory leak because both the cache and the kobject
>     remain alive on kobject_init_and_add() failure.
> 
>     If SLUB tries to create an alias for a cache without sysfs files,
>     its symbolic link will not be generated.
> 
>     Since a slab cache might not have associated sysfs files, call kobject_del()
>     only if such files exist.

-- 
Cheers,
Harry / Hyeonggon