[PATCH] gpiolib: fix leaked descriptor labels in gpiodev_release()

[PATCH] gpiolib: fix leaked descriptor labels in gpiodev_release()

[Breno Leitao]

We are seeing kmemleak report a leaked descriptor label on linux-next.

  unreferenced object 0xffff0005d420f280 (size 32):
    comm "gpio-cdev-uaf", pid 21987, jiffies 4297166145
    backtrace (crc 7ff222d9):
      kmemleak_alloc+0x40/0xd0
      __kmalloc_noprof+0x300/0x670
      desc_set_label+0x50/0x190
      gpiod_request_commit+0x1e8/0x358
      gpiod_request+0x88/0x290
      gpio_ioctl+0x7e4/0x1b48
      __arm64_sys_ioctl+0xc10/0x1360

The test requests a line, removes the gpio-sim chip under it, and only
then closes the request. By that time gpiochip_remove() has cleared
gdev->chip, so gpiod_free_commit() skips desc_set_label(desc, NULL), and
gpiodev_release() frees the descriptor array without the labels still
attached to it.

Free those labels in gpiodev_release(). No reader can reach the
descriptors once the device is released, so they can be freed directly
rather than through call_srcu(). gdev->descs is NULL there when
gpiochip_add_data_with_key() failed to allocate it.

Fixes: 35b545332b80 ("gpio: remove gpio_lock")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 drivers/gpio/gpiolib.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 033c6fce4fc8da..3d301234dff44d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -896,11 +896,16 @@ static void gpiochip_free_remaining_irqs(struct gpio_chip *gc)
 static void gpiodev_release(struct device *dev)
 {
 	struct gpio_device *gdev = to_gpio_device(dev);
+	unsigned int i;
 
 	/* Call pending kfree()s for descriptor labels. */
 	synchronize_srcu(&gdev->desc_srcu);
 	cleanup_srcu_struct(&gdev->desc_srcu);
 
+	/* Lines released after the chip was removed still hold their label. */
+	for (i = 0; gdev->descs && i < gdev->ngpio; i++)
+		kfree(rcu_access_pointer(gdev->descs[i].label));
+
 	ida_free(&gpio_ida, gdev->id);
 	kfree_const(gdev->label);
 	kfree(gdev->descs);

---
base-commit: 6d582d78fad9d828e575ca0cdcff8ea47a77220b
change-id: 20261113-gpio-label-leak-4c296355d62b

Best regards,
--  
Breno Leitao <leitao@debian.org>

Re: [PATCH] gpiolib: fix leaked descriptor labels in gpiodev_release()

[Andy Shevchenko]

On Fri, Nov 13, 2026 at 06:38:28AM -0800, Breno Leitao wrote:
> We are seeing kmemleak report a leaked descriptor label on linux-next.
> 
>   unreferenced object 0xffff0005d420f280 (size 32):
>     comm "gpio-cdev-uaf", pid 21987, jiffies 4297166145
>     backtrace (crc 7ff222d9):

>       kmemleak_alloc+0x40/0xd0
>       __kmalloc_noprof+0x300/0x670

Unneeded in the report

>       desc_set_label+0x50/0x190
>       gpiod_request_commit+0x1e8/0x358
>       gpiod_request+0x88/0x290
>       gpio_ioctl+0x7e4/0x1b48

>       __arm64_sys_ioctl+0xc10/0x1360

Ditto.

As documented in Submitting Patches, leave only significant lines in
the backtrace.

> The test requests a line, removes the gpio-sim chip under it, and only
> then closes the request. By that time gpiochip_remove() has cleared
> gdev->chip, so gpiod_free_commit() skips desc_set_label(desc, NULL), and
> gpiodev_release() frees the descriptor array without the labels still
> attached to it.
> 
> Free those labels in gpiodev_release(). No reader can reach the
> descriptors once the device is released, so they can be freed directly
> rather than through call_srcu(). gdev->descs is NULL there when
> gpiochip_add_data_with_key() failed to allocate it.

Hmm... There are so many patches are flying in this area. Can you for the
starter elaborate which Linux Next tag you are using?

...

> +	unsigned int i;

It's okay do define it inside the for-loop.

...

> +	/* Lines released after the chip was removed still hold their label. */
> +	for (i = 0; gdev->descs && i < gdev->ngpio; i++)
> +		kfree(rcu_access_pointer(gdev->descs[i].label));

Sounds to me like something that Bart addressed very recently.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: fix leaked descriptor labels in gpiodev_release()

[Breno Leitao]

On Fri, Nov 13, 2026 at 05:29:53PM +0200, Andy Shevchenko wrote:
> On Fri, Nov 13, 2026 at 06:38:28AM -0800, Breno Leitao wrote:
> > We are seeing kmemleak report a leaked descriptor label on linux-next.
> > 
> >   unreferenced object 0xffff0005d420f280 (size 32):
> >     comm "gpio-cdev-uaf", pid 21987, jiffies 4297166145
> >     backtrace (crc 7ff222d9):
> 
> >       kmemleak_alloc+0x40/0xd0
> >       __kmalloc_noprof+0x300/0x670
> 
> Unneeded in the report
> 
> >       desc_set_label+0x50/0x190
> >       gpiod_request_commit+0x1e8/0x358
> >       gpiod_request+0x88/0x290
> >       gpio_ioctl+0x7e4/0x1b48
> 
> >       __arm64_sys_ioctl+0xc10/0x1360
> 
> Ditto.
> 
> As documented in Submitting Patches, leave only significant lines in
> the backtrace.

Ack, I will drop them in v2.

> > The test requests a line, removes the gpio-sim chip under it, and only
> > then closes the request. By that time gpiochip_remove() has cleared
> > gdev->chip, so gpiod_free_commit() skips desc_set_label(desc, NULL), and
> > gpiodev_release() frees the descriptor array without the labels still
> > attached to it.
> > 
> > Free those labels in gpiodev_release(). No reader can reach the
> > descriptors once the device is released, so they can be freed directly
> > rather than through call_srcu(). gdev->descs is NULL there when
> > gpiochip_add_data_with_key() failed to allocate it.
> 
> Hmm... There are so many patches are flying in this area. Can you for the
> starter elaborate which Linux Next tag you are using?

Today's tree, aka next-20261112. The splat comes from a next-20261112
kernel running the gpio selftests (gpio-cdev-uaf.sh). The patch is based
on that tag, and with it the leak goes away.

> ...
> 
> > +	unsigned int i;
> 
> It's okay do define it inside the for-loop.

Ack, I will move it into the for loop.

> 
> ...
> 
> > +	/* Lines released after the chip was removed still hold their label. */
> > +	for (i = 0; gdev->descs && i < gdev->ngpio; i++)
> > +		kfree(rcu_access_pointer(gdev->descs[i].label));
> 
> Sounds to me like something that Bart addressed very recently.

If you mean commit 82028344caee ("gpiolib: synchronize updates of
descriptor labels"), it is already in next-20261112, and the leak still
happens with it. That commit serialize concurrent label updates. 

This leak is different: once gpiochip_remove() has cleared gdev->chip,
gpiod_free_commit() skips desc_set_label(desc, NULL), so the label of
any line released after that is never freed.

Thanks for the review,
--breno