[PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[Hongling Zeng]

When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
is not properly cleaned up, causing a memory leak.

According to the kobject API documentation, when kobject_init_and_add()
returns an error, the caller must call kobject_put() to properly clean
up the memory associated with the object. The current code only frees
the 'name' string but forgets to release the kobject reference.

Fix this by calling kobject_put() before jumping to the error label.

Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
 mm/slub.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 9ec774dc7009..fec2cd08d129 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -9690,8 +9690,10 @@ 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)
+	if (err) {
+		kobject_put(&s->kobj);
 		goto out;
+	}
 
 	if (!unmergeable) {
 		/* Setup first alias */
-- 
2.25.1

Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[Harry Yoo]

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



On 7/13/26 2:58 PM, Hongling Zeng wrote:
> When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
> is not properly cleaned up, causing a memory leak.
> 
> According to the kobject API documentation, when kobject_init_and_add()
> returns an error, the caller must call kobject_put() to properly clean
> up the memory associated with the object. The current code only frees
> the 'name' string but forgets to release the kobject reference.

This was intentional, please see commit 2420baa8e046 ("mm/slab: Allow
cache creation to proceed even if sysfs registration fails").
> Fix this by calling kobject_put() before jumping to the error label.
> 
> Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
> ---


Uh, there was a similar attempt recently...

https://lore.kernel.org/linux-mm/gimwkjjpvwu2sg5625b3eeatw2vhv7rs6enm3vepdduhcefbf5@xen5iec7sn3z

Sounds like we need a comment saying it is intentional!

-- 
Cheers,
Harry / Hyeonggon


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

Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[Hongling Zeng]

在 2026年07月13日 14:07, Harry Yoo 写道:
>
> On 7/13/26 2:58 PM, Hongling Zeng wrote:
>> When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
>> is not properly cleaned up, causing a memory leak.
>>
>> According to the kobject API documentation, when kobject_init_and_add()
>> returns an error, the caller must call kobject_put() to properly clean
>> up the memory associated with the object. The current code only frees
>> the 'name' string but forgets to release the kobject reference.
> This was intentional, please see commit 2420baa8e046 ("mm/slab: Allow
> cache creation to proceed even if sysfs registration fails").
   Thank you for the clarification. I see now that this was an intentional
   design choice to allow cache creation to proceed even when sysfs
   registration fails.

>> Fix this by calling kobject_put() before jumping to the error label.
>>
>> Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>> ---
>
> Uh, there was a similar attempt recently...
>
> https://lore.kernel.org/linux-mm/gimwkjjpvwu2sg5625b3eeatw2vhv7rs6enm3vepdduhcefbf5@xen5iec7sn3z
>
> Sounds like we need a comment saying it is intentional!
>
  Good idea. Would a patch adding a comment like this be useful?
           err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s", 
name);
   +       /*
   +        * Note: Intentionally not calling kobject_put() on error.
   +        *
   +        * The kobject release callback (slab_kmem_cache_release) would
   +        * free the entire kmem_cache structure. However, sysfs
   +        * registration failures are treated as non-fatal - the cache
   +        * continues to be used. See commit 2420baa8e046 ("mm/slab: Allow
   +        * cache creation to proceed even if sysfs registration fails").
   +        */
           if (err)
                   goto out;

Thanks!

Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[Harry Yoo]

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



On 7/13/26 3:14 PM, Hongling Zeng wrote:
> 
> 在 2026年07月13日 14:07, Harry Yoo 写道:
>>
>> On 7/13/26 2:58 PM, Hongling Zeng wrote:
>>> When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
>>> is not properly cleaned up, causing a memory leak.
>>>
>>> According to the kobject API documentation, when kobject_init_and_add()
>>> returns an error, the caller must call kobject_put() to properly clean
>>> up the memory associated with the object. The current code only frees
>>> the 'name' string but forgets to release the kobject reference.
>> This was intentional, please see commit 2420baa8e046 ("mm/slab: Allow
>> cache creation to proceed even if sysfs registration fails").
>   Thank you for the clarification. I see now that this was an intentional
>   design choice to allow cache creation to proceed even when sysfs
>   registration fails.
> 
>>> Fix this by calling kobject_put() before jumping to the error label.
>>>
>>> Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
>>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>>> ---
>>
>> Uh, there was a similar attempt recently...
>>
>> https://lore.kernel.org/linux-mm/
>> gimwkjjpvwu2sg5625b3eeatw2vhv7rs6enm3vepdduhcefbf5@xen5iec7sn3z
>>
>> Sounds like we need a comment saying it is intentional!
>>
>  Good idea. Would a patch adding a comment like this be useful?
>
>           err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s",
> name);
>   +       /*
>   +        * Note: Intentionally not calling kobject_put() on error.
>   +        *
>   +        * The kobject release callback (slab_kmem_cache_release) would
>   +        * free the entire kmem_cache structure. However, sysfs
>   +        * registration failures are treated as non-fatal - the cache
>   +        * continues to be used. See commit 2420baa8e046 ("mm/slab: Allow
>   +        * cache creation to proceed even if sysfs registration fails").
>   +        */

Could we make it bit more concise please?

Something like

"Intentionally skip kobject_put(). See commit 2420baa8e046 ("mm/slab:
Allow cache creation to proceed even if sysfs registration fails")"

>           if (err)
>                   goto out;
>  

-- 
Cheers,
Harry / Hyeonggon


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

Re: [PATCH] mm/slub: fix kobject leak in sysfs_slab_add error path

[Hongling Zeng]

在 2026年07月13日 14:27, Harry Yoo 写道:
>
> On 7/13/26 3:14 PM, Hongling Zeng wrote:
>> 在 2026年07月13日 14:07, Harry Yoo 写道:
>>> On 7/13/26 2:58 PM, Hongling Zeng wrote:
>>>> When kobject_init_and_add() fails in sysfs_slab_add(), the kobject
>>>> is not properly cleaned up, causing a memory leak.
>>>>
>>>> According to the kobject API documentation, when kobject_init_and_add()
>>>> returns an error, the caller must call kobject_put() to properly clean
>>>> up the memory associated with the object. The current code only frees
>>>> the 'name' string but forgets to release the kobject reference.
>>> This was intentional, please see commit 2420baa8e046 ("mm/slab: Allow
>>> cache creation to proceed even if sysfs registration fails").
>>    Thank you for the clarification. I see now that this was an intentional
>>    design choice to allow cache creation to proceed even when sysfs
>>    registration fails.
>>
>>>> Fix this by calling kobject_put() before jumping to the error label.
>>>>
>>>> Fixes: 54b6a731025f ("slub: fix leak of 'name' in sysfs_slab_add")
>>>> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
>>>> ---
>>> Uh, there was a similar attempt recently...
>>>
>>> https://lore.kernel.org/linux-mm/
>>> gimwkjjpvwu2sg5625b3eeatw2vhv7rs6enm3vepdduhcefbf5@xen5iec7sn3z
>>>
>>> Sounds like we need a comment saying it is intentional!
>>>
>>   Good idea. Would a patch adding a comment like this be useful?
>>
>>            err = kobject_init_and_add(&s->kobj, &slab_ktype, NULL, "%s",
>> name);
>>    +       /*
>>    +        * Note: Intentionally not calling kobject_put() on error.
>>    +        *
>>    +        * The kobject release callback (slab_kmem_cache_release) would
>>    +        * free the entire kmem_cache structure. However, sysfs
>>    +        * registration failures are treated as non-fatal - the cache
>>    +        * continues to be used. See commit 2420baa8e046 ("mm/slab: Allow
>>    +        * cache creation to proceed even if sysfs registration fails").
>>    +        */
> Could we make it bit more concise please?
>
> Something like
>
> "Intentionally skip kobject_put(). See commit 2420baa8e046 ("mm/slab:
> Allow cache creation to proceed even if sysfs registration fails")"
>
>>            if (err)
>>                    goto out;
>>   
   Thank you for the suggestion. Here's the simplified version:

   [PATCH v1] mm/slub: add comment explaining intentional kobject handling
   in sysfs_slab_add

   Please review.

   Thanks!

   Best regards,
   Hongling Zeng