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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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