Re: [PATCH] platform/x86: dell-wmi-sysman: fix kobject leak on populate failure

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Feb 07, 2026 at 11:52:11AM -0500, Daniel Hodges wrote:
> On Sat, Feb 07, 2026 at 08:48:34AM +0100, Greg KH wrote:
> > On Fri, Feb 06, 2026 at 06:16:42PM -0500, Daniel Hodges wrote:
> > > When populate_enum_data(), populate_int_data(), populate_str_data(),
> > > or populate_po_data() fails after a successful kobject_init_and_add(),
> > > the code jumps to err_attr_init without calling kobject_put() on
> > > attr_name_kobj, leaking the kobject and its associated memory.
> > > 
> > > Add the missing kobject_put() call before the goto to properly release
> > > the kobject on error.
> > > 
> > > Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Daniel Hodges <git@danielhodges.dev>
> > > ---
> > >  drivers/platform/x86/dell/dell-wmi-sysman/sysman.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/platform/x86/dell/dell-wmi-sysman/sysman.c b/drivers/platform/x86/dell/dell-wmi-sysman/sysman.c
> > > index f5402b714657..d9f6d24c84d6 100644
> > > --- a/drivers/platform/x86/dell/dell-wmi-sysman/sysman.c
> > > +++ b/drivers/platform/x86/dell/dell-wmi-sysman/sysman.c
> > > @@ -497,6 +497,7 @@ static int init_bios_attributes(int attr_type, const char *guid)
> > >  		if (retval) {
> > >  			pr_debug("failed to populate %s\n",
> > >  				elements[ATTR_NAME].string.pointer);
> > > +			kobject_put(attr_name_kobj);
> > >  			goto err_attr_init;
> > >  		}
> > >  
> > 
> > The "larger" problem with this driver is its use of raw kobjects.  No
> > driver should be doing that, it is hiding all of this information from
> > userspace tools by doing so, and there's loads of race conditions
> > happening with the creation of these files.  It should be fixed by just
> > using normal device attributes and not attempting to custom create
> > kobjects by hand like this (as it is very easy to get things wrong, as
> > this patch shows.)
> > 
> > thanks,
> > 
> > greg k-h
> 
> Yeah, that makes sense. I think your point of finding "bad patterns" in
> usage would also be really helpful for code analysis tools. If there's
> some canonical docs on various antipatterns it would be pretty helpful.

Huge hint, any driver that calls any sysfs_*() function or touches a
kobject at all, is probably doing things wrong.  Start there and see
what you find :)

thanks,

greg k-h