CVE-2026-31732: gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()
In the Linux kernel, the following vulnerability has been resolved:
gpio: Fix resource leaks on errors in gpiochipadddatawithkey()
Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"), gdev->dev.release is unset. As a result, the reference count to gdev->dev isn't dropped on the error handling paths.
Drop the reference on errors.
Also reorder the instructions to make the error handling simpler. Now gpiochipadddatawithkey() roughly looks like:
>>> Some memory allocation. Go to ERR ZONE 1 on errors. >>> deviceinitialize().
gpiodevrelease() takes over the responsibility for freeing the resources of gdev->dev. The subsequent error handling paths shouldn't go through ERR ZONE 1 again which leads to double free.
>>> Some initialization mainly on gdev. >>> The rest of initialization. Go to ERR ZONE 2 on errors. >>> Chip registration success and exit.
>>> ERR ZONE 2. gpiodeviceput() and exit. >>> ERR ZONE 1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 7.0.0-1006.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.14-1 - Compensating control
In gpiochip_add_data_with_key(), drop the gdev->dev reference on error paths by calling gpio_device_put() and exiting through the appropriate error zone; reorder the error handling so subsequent paths do not re-enter ERR ZONE 1 and cause a double free.
Event History
Frequently Asked Questions
What condition triggers the affected error path?
The issue is triggered when gpiochip_add_data_with_key() encounters an error after device initialization but before GPIO chip registration completes. The affected cleanup path fails to drop the reference to gdev->dev because its release callback is unset.
What is the practical impact of the flaw?
Failed GPIO chip registration can leak resources and references associated with the GPIO device. The provided severity vector indicates local access, low attack complexity, and low privileges are required, with availability impact but no stated confidentiality or integrity impact.
Which systems should be reviewed?
Review systems running the Linux kernel, including the listed Ubuntu kernel variants: linux-riscv, linux-realtime, linux-raspi, linux-hwe-edge, linux-azure, linux-gcp, and linux-azure-fde. Exposure depends on reaching the GPIO chip registration error handling path.
How can the issue be remediated?
Apply a kernel update containing the referenced stable fixes. The fix drops the GPIO device reference on the relevant error paths and separates cleanup zones to avoid a double free after device initialization.