public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails
@ 2026-01-31  0:09 Salah Triki
  2026-01-31 12:21 ` Benjamin Coddington
  0 siblings, 1 reply; 4+ messages in thread
From: Salah Triki @ 2026-01-31  0:09 UTC (permalink / raw)
  To: Trond Myklebust, Anna Schumaker; +Cc: linux-nfs, linux-kernel, Salah Triki

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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails
  2026-01-31  0:09 [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails Salah Triki
@ 2026-01-31 12:21 ` Benjamin Coddington
  2026-01-31 16:54   ` Trond Myklebust
  0 siblings, 1 reply; 4+ messages in thread
From: Benjamin Coddington @ 2026-01-31 12:21 UTC (permalink / raw)
  To: Salah Triki; +Cc: Trond Myklebust, Anna Schumaker, linux-nfs, linux-kernel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails
  2026-01-31 12:21 ` Benjamin Coddington
@ 2026-01-31 16:54   ` Trond Myklebust
  2026-01-31 19:17     ` Salah Triki
  0 siblings, 1 reply; 4+ messages in thread
From: Trond Myklebust @ 2026-01-31 16:54 UTC (permalink / raw)
  To: Benjamin Coddington, Salah Triki; +Cc: Anna Schumaker, linux-nfs, linux-kernel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails
  2026-01-31 16:54   ` Trond Myklebust
@ 2026-01-31 19:17     ` Salah Triki
  0 siblings, 0 replies; 4+ messages in thread
From: Salah Triki @ 2026-01-31 19:17 UTC (permalink / raw)
  To: Trond Myklebust
  Cc: Benjamin Coddington, Anna Schumaker, linux-nfs, linux-kernel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-01-31 19:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-31  0:09 [PATCH] nfs: fix memory leak in nfs_sysfs_init if kset_register fails Salah Triki
2026-01-31 12:21 ` Benjamin Coddington
2026-01-31 16:54   ` Trond Myklebust
2026-01-31 19:17     ` Salah Triki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox