Cloudanix VulnDB

CVE-2026-99189

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in low-level hardware driver code can crash the entire system if an interrupt arrives at exactly the wrong moment during startup.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in mxc_gpio driver allows chained IRQ handler to execute before IRQ domain, generic chip, and port list are initialized, resulting in NULL dereference or list walk on incomplete data; probe failure paths also leave dangling handler referencing freed memory.

Why it matters to the business

Kernel instability or crashes on embedded Linux systems using i.MX GPIO, causing denial of service and potential system reboot loops during driver load.

How an attack unfolds

An attacker with ability to trigger GPIO interrupts during early driver probe can cause the handler to run on unready structures, leading to kernel panic; no named threat actors or public exploits known at publication.

How to fix it

Apply the upstream Linux kernel patch that relocates chained handler installation after list_add_tail and all dependent structures are initialized; rebuild and deploy fixed kernel on affected systems.

How to confirm the fix worked

Confirm kernel source contains handler registration after irq_domain_create_legacy and list_add_tail; test probe success/failure paths under interrupt load to ensure no dangling handlers remain.

Typical attack path

  1. Trigger GPIO hardware interrupt while mxc_gpio probe is executing
  2. mx3_gpio_irq_handler or mx2_gpio_irq_handler runs before domain or port list is valid
  3. generic_handle_domain_irq receives NULL domain or list walk hits incomplete entry
  4. Kernel oops or memory corruption occurs

How to detect it

Inspect kernel logs for oops or panic mentioning mx3_gpio_irq_handler, mx2_gpio_irq_handler, mxc_update_irq_chained_handler or generic_handle_domain_irq with NULL domain; correlate with driver probe timestamps.

  • mx3_gpio_irq_handler
  • mx2_gpio_irq_handler
  • mxc_update_irq_chained_handler
  • port->domain still NULL

What your security team should do

  • Prioritize kernel update on all i.MX-based embedded devices within maintenance windows
  • Monitor for related kernel oops reports in logs
  • Review downstream device trees and GPIO usage for exposure

The record

In the Linux kernel, the following vulnerability has been resolved: gpio: mxc: fix race between chained IRQ handler install and probe completion mxc_update_irq_chained_handler() is called before the IRQ domain, the generic IRQ chip, and the port list entry are set up. If an interrupt arrives in that window: - mx3_gpio_irq_handler() calls generic_handle_domain_irq() with port->domain still NULL. - mx2_gpio_irq_handler() walks mxc_gpio_ports, but the port has not been added to the list yet. Additionally, if any of the subsequent probe steps (gpio_generic_chip_init(), devm_gpiochip_add_data(), irq_domain_create_legacy(), or mxc_gpio_init_gc()) fail, the error paths never unregister the chained handler, leaving a dangling handler that points at freed memory. Move the handler installation after all its dependencies are ready and after list_add_tail(), so the handler is never live while the data structures it touches are incomplete, and is never installed if probe fails.

Affected packages

Ecosystem Package Introduced Fixed