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 issue was found by a static analysis tool I am developing.

Fixes: 26e4f2057516 ("slub: Fix possible format string bug.")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 mm/slub.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 2b2d33cc735c..9f0f03460b4d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -9492,7 +9492,7 @@ static int sysfs_slab_add(struct kmem_cache *s)
 	s->kobj.kset = kset;
 	err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", name);
 	if (err)
-		goto out;
+		goto out_put_kobj;
 
 	err = sysfs_create_group(&s->kobj, &slab_attr_group);
 	if (err)
@@ -9506,6 +9506,9 @@ static int sysfs_slab_add(struct kmem_cache *s)
 	if (!unmergeable)
 		kfree(name);
 	return err;
+out_put_kobj:
+	kobject_put(&s->kobj);
+	goto out;
 out_del_kobj:
 	kobject_del(&s->kobj);
 	goto out;
-- 
2.43.0

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