When `kset_register()` fails, it does not clean up the underlying
kobject. Calling `kfree()` directly is incorrect because the kobject
within the kset has already been initialized, and its internal
resources or reference counting must be handled properly.

As stated in the kobject documentation, once a kobject is registered
(or even just initialized), you must use `kobject_put()` instead of
`kfree()` to let the reference counting mechanism perform the cleanup
via the ktype's release callback.

This patch replaces the incorrect `kfree()` with `kobject_put()` in the
error path of `nfs_sysfs_init()`.

Fixes: 943aef2dbcf75 ("NFS: Open-code the nfs_kset
kset_create_and_add()")

Signed-off-by: Salah Triki <salah.triki@gmail.com>
---
 fs/nfs/sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/sysfs.c b/fs/nfs/sysfs.c
index ea6e6168092b..6e39cd69ed44 100644
--- a/fs/nfs/sysfs.c
+++ b/fs/nfs/sysfs.c
@@ -59,7 +59,7 @@ int nfs_sysfs_init(void)
 
 	ret = kset_register(nfs_kset);
 	if (ret) {
-		kfree(nfs_kset);
+		kset_put(nfs_kset);
 		return ret;
 	}
 
-- 
2.43.0

On 30 Jan 2026, at 19:09, Salah Triki wrote:

> When `kset_register()` fails, it does not clean up the underlying
> kobject. Calling `kfree()` directly is incorrect because the kobject
> within the kset has already been initialized, and its internal
> resources or reference counting must be handled properly.
>
> As stated in the kobject documentation, once a kobject is registered
> (or even just initialized), you must use `kobject_put()` instead of
> `kfree()` to let the reference counting mechanism perform the cleanup
> via the ktype's release callback.

I don't think this patch is correct - the kobj is not initialized yet, and
on error return from kset_register() you'll likely get the WARN from
lib/kobject.c:734 kobject_put() when calling kset_put().

That said it does look like that path might leak kobj->name, you might
look at doing kfree_const() on it.

Did you test this - how did you determine this was a problem?

Ben

On Sat, 2026-01-31 at 07:21 -0500, Benjamin Coddington wrote:
> On 30 Jan 2026, at 19:09, Salah Triki wrote:
> 
> > When `kset_register()` fails, it does not clean up the underlying
> > kobject. Calling `kfree()` directly is incorrect because the
> > kobject
> > within the kset has already been initialized, and its internal
> > resources or reference counting must be handled properly.
> > 
> > As stated in the kobject documentation, once a kobject is
> > registered
> > (or even just initialized), you must use `kobject_put()` instead of
> > `kfree()` to let the reference counting mechanism perform the
> > cleanup
> > via the ktype's release callback.
> 
> I don't think this patch is correct - the kobj is not initialized
> yet, and
> on error return from kset_register() you'll likely get the WARN from
> lib/kobject.c:734 kobject_put() when calling kset_put().
> 
> That said it does look like that path might leak kobj->name, you
> might
> look at doing kfree_const() on it.
> 
> Did you test this - how did you determine this was a problem?
> 
> Ben

If you take a look at kset_register(), you'll see that it does free the
kobj.name pointer if there is an error when adding the kobject.

IOW: there is no bug in the current code.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

On Sat, Jan 31, 2026 at 11:54:06AM -0500, Trond Myklebust wrote:
> 
> If you take a look at kset_register(), you'll see that it does free the
> kobj.name pointer if there is an error when adding the kobject.
> 
> IOW: there is no bug in the current code.

Thanks for the clarification.

You're right, kset_register() already frees kobj.name on failure, and the
kobject is not fully initialized at that point. I double-checked the
error path in kset_register(), and the current cleanup in nfs_sysfs_init()
is correct.

Apologies for the noise — I'll drop this patch.

Thanks for taking the time to explain.

Salah