CVE-2026-92481: pinctrl: mediatek: free EINT resources on unbind
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mediatek: free EINT resources on unbind
mtkeintdoinit() creates an IRQ domain, populates it with a mapping for every EINT line and installs a chained handler on the parent interrupt, but none of these are ever released. This was harmless while the drivers were built-in, but now that they can be built as modules and unbound/rmmod'd it leaves behind a dangling IRQ domain, interrupt mappings whose chip data points at freed memory, and a chained handler that keeps firing into that freed data.
The plain allocations in mtkeintdoinit() already use the device-managed devm() helpers, so tear the remaining resources down the same way: register a devm action that detaches the chained handler, waits for any in-flight handler to finish, disposes of the per-line mappings and removes the IRQ domain. This mirrors the device-managed lifecycle adopted for the GPIO chip and keeps the whole EINT setup self-cleaning on unbind.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the kernel fix that registers a devm action to detach the chained EINT handler, waits for any in-flight handler to finish, disposes per-line mappings, and removes/destroys the IRQ domain so unbind/rmmod does not leave a dangling IRQ domain or freed-memory-backed chip data.
Linux kernel (pinctrl: mediatek) mediatek free EINT resources on unbind = implemented via devm action and device-managed teardown
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the affected MediaTek pinctrl EINT driver are exposed when that driver is built as a module and is unbound or removed. The issue was described as harmless when the drivers were built into the kernel.
What event triggers the unsafe condition?
Unbinding or removing the module triggers it. The driver previously left its IRQ domain, per-line interrupt mappings, and parent chained interrupt handler registered after the driver's memory had been freed.
What can be done if the fix cannot be deployed immediately?
Avoid unbinding or removing the affected MediaTek pinctrl EINT module. Keeping the driver built into the kernel avoids the module-unbind lifecycle that creates the dangling resources.
How can an administrator determine whether a system may already be affected?
A system may be affected if it has used an affected MediaTek pinctrl EINT driver as a loadable module and that module has been unbound or removed. The remaining interrupt mappings and chained handler can retain references to freed driver memory.