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

[Breno Leitao <leitao@debian.org>]

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