CVE-2026-92482: pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mediatek: use devmgpiochipadddata() for GPIO chip
The gpiochip is allocated with device-managed memory but registered with the non-managed gpiochipadddata(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpiochip's memory while it is still registered, causing a use-after-free.
Register it with devmgpiochipadddata() so it shares the same device-managed lifecycle, which also lets the manual gpiochipremove() error paths go away.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the pinctrl: mediatek GPIO chip registration to use devm_gpiochip_add_data() so the gpio_chip shares the device-managed lifecycle and is not freed while still registered (avoid the use-after-free when drivers/modules are unbound/rmmod'd).
pinctrl: mediatek (Linux kernel GPIO controller driver) registration of gpio_chip via devm_gpiochip_add_data() = use devm_gpiochip_add_data() instead of gpiochip_add_data()
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The issue is relevant when the affected MediaTek pinctrl drivers are built as loadable modules and can be unbound or removed. The described lifetime mismatch was harmless when the drivers were built into the kernel.
What action triggers the use-after-free condition?
Unbinding the driver or removing its module can cause device-managed memory for the gpio_chip to be freed while the chip remains registered. Subsequent use of that registered gpio_chip can then access freed memory.