linux-kernel - Re: [PATCH 01/23] gpiolib: Correct wrong kfree() usage for `kobj->name`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2026011600-thirsty-troubling-dc76@gregkh>
Date: Fri, 16 Jan 2026 14:27:29 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Tzung-Bi Shih <tzungbi@...nel.org>, Jonathan Corbet <corbet@....net>,
	Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
	linux-kselftest@...r.kernel.org,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>,
	Jason Gunthorpe <jgg@...dia.com>, linux-gpio@...r.kernel.org,
	stable@...r.kernel.org, Benson Leung <bleung@...omium.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Linus Walleij <linusw@...nel.org>
Subject: Re: [PATCH 01/23] gpiolib: Correct wrong kfree() usage for
 `kobj->name`

On Fri, Jan 16, 2026 at 01:15:17PM +0000, Bartosz Golaszewski wrote:
> On Fri, 16 Jan 2026 09:10:14 +0100, Tzung-Bi Shih <tzungbi@...nel.org> said:
> > `kobj->name` should be freed by kfree_const()[1][2].  Correct it.
> >
> > [1] https://elixir.bootlin.com/linux/v6.18/source/lib/kasprintf.c#L41
> > [2] https://elixir.bootlin.com/linux/v6.18/source/lib/kobject.c#L695
> >
> 
> Please don't add links third-party groks to git commit messages.
> 
> > Cc: stable@...r.kernel.org
> > Fixes: c351bb64cbe6 ("gpiolib: free device name on error path to fix kmemleak")
> > Signed-off-by: Tzung-Bi Shih <tzungbi@...nel.org>
> > ---
> >  drivers/gpio/gpiolib.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 5eb918da7ea2..ba9323432e3a 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -1263,7 +1263,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> >  err_free_descs:
> >  	kfree(gdev->descs);
> >  err_free_dev_name:
> > -	kfree(dev_name(&gdev->dev));
> > +	kfree_const(dev_name(&gdev->dev));
> >  err_free_ida:
> >  	ida_free(&gpio_ida, gdev->id);
> >  err_free_gdev:
> > --
> > 2.52.0.457.g6b5491de43-goog
> >
> >
> 
> I've never paid attention to this bit but it really looks broken. I understand
> that this string won't get freed until we initialize refcounting on the
> underlying kobject but reaching two abstraction layers below to get the string
> for freeing out of the kobject looks incorrect to me.
> 
> It's also one of only two instances of doing kfree(dev_name(dev)), the other
> one being in drivers/scsi/hosts.c.

That one is wrong, I already rejected it :)

> It looks to me that the device name is not really used in
> gpiochip_add_data_with_key(). Can we move dev_set_name() after
> device_initialize()?

This should be cleaned up automatically by the driver core, no need to
free this on its own.

thanks,

greg k-h