CVE-2026-92481
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A driver bug in certain chips can leave behind broken interrupt handling code after the driver is removed, which may cause crashes or let attackers run code if they can unload the driver.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in the MediaTek pinctrl EINT driver: mtk_eint_do_init allocates an IRQ domain, per-line mappings, and a chained interrupt handler that are never released on driver unbind or module removal, leaving mappings whose chip data point at freed memory and a handler that continues to execute into that memory.
Why it matters to the business
Unloading or failing to cleanly remove the affected pinctrl driver can cause kernel instability, crashes, or memory corruption on systems that dynamically load the module, increasing operational risk for devices that rely on MediaTek pin controllers.
How an attack unfolds
An attacker with the ability to load/unload the pinctrl-mtk module (or trigger unbind) causes the driver to free its IRQ resources while the chained handler and mappings remain active; subsequent interrupt delivery dereferences the now-freed chip data, enabling use-after-free exploitation.
How to fix it
Update to a Linux kernel containing the fix that registers a devm action to detach the chained handler, dispose of mappings, and remove the IRQ domain on unbind; rebuild and redeploy any out-of-tree modules that depend on the corrected pinctrl-mtk code.
How to confirm the fix worked
Confirm the presence of the devm action teardown in mtk_eint_do_init and verify that rmmod or unbind no longer leaves an IRQ domain or active chained handler; inspect /proc/interrupts and kernel debug logs for orphaned EINT mappings after module removal.
Typical attack path
- Obtain ability to trigger module unload or device unbind on the target system
- Unload the pinctrl driver, freeing IRQ domain and mappings while leaving the chained handler registered
- Trigger an EINT interrupt that invokes the chained handler
- Execute code or crash via the dangling references to freed memory
How to detect it
Search kernel logs for warnings about dangling IRQ domains or chained handlers after pinctrl module removal; monitor for crashes in the EINT handler path or use-after-free reports in dmesg following unbind events.
What your security team should do
- Prioritize kernel updates on all MediaTek-based systems that may load pinctrl as a module
- Audit custom kernels and out-of-tree drivers for similar missing devm teardown patterns
- Add monitoring for unexpected module unloads on production devices
The record
In the Linux kernel, the following vulnerability has been resolved: pinctrl: mediatek: free EINT resources on unbind mtk_eint_do_init() 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 mtk_eint_do_init() 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 packages
| Ecosystem | Package | Introduced | Fixed |
|---|