Cloudanix VulnDB

CVE-2026-98903

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in Linux mailbox code for certain NXP chips can let an interrupt fire after its handler has been removed, potentially breaking device communication and requiring a reboot.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in imx mailbox driver where RX interrupt enable bit can be re-enabled by ISR after shutdown disables it, leaving a removed channel able to trigger interrupts on shared handlers and causing irq-core to shut down the line with 'nobody cared'.

Why it matters to the business

Potential system instability or denial of service on affected embedded Linux devices using i.MX mailbox hardware; low likelihood of direct data loss or remote code execution but can disrupt device operation and require reboots.

How an attack unfolds

An attacker with local code execution or the ability to trigger channel teardown races against the ISR on a multi-CPU system. By timing shutdown and interrupt events the attacker can cause the interrupt to be mishandled, resulting in the kernel disabling the shared IRQ and breaking other mailbox users.

How to fix it

Apply the upstream kernel patch that introduces the imx_mu_con_priv::shutdown flag and the associated imx_mu_xcr_clr_shut / imx_mu_xcr_set_act helpers; rebuild and deploy the fixed kernel to all affected i.MX platforms.

How to confirm the fix worked

Confirm the presence of the shutdown flag and the two new helper functions in the imx-mu.c source; boot the patched kernel and exercise mailbox channel open/close under load while monitoring for 'nobody cared' messages.

Typical attack path

  1. Obtain local execution or control over a mailbox channel user
  2. Trigger concurrent imx_mu_shutdown on one CPU while imx_mu_isr runs on another
  3. Win the race so that the shutdown clears the enable bit then the ISR re-enables it
  4. Force the removed channel to generate an interrupt, causing 'nobody cared' handling
  5. Observe or exploit resulting loss of mailbox functionality or system instability

How to detect it

Search kernel logs and dmesg for 'nobody cared' messages referencing the mailbox IRQ; inspect call traces containing imx_mu_isr and imx_mu_shutdown around the same timestamp.

What your security team should do

  • Prioritize patching of any i.MX-based devices that use the mailbox driver
  • Monitor kernel logs for 'nobody cared' IRQ messages on affected hardware
  • Apply the fix within normal kernel update cycles given low EPSS and no known exploitation

The record

In the Linux kernel, the following vulnerability has been resolved: mailbox: imx: Add a channel shutdown field sashiko complained about possible teardown problem. The scenario CPU 0 CPU 1 imx_mu_isr() imx_mu_shutdown() imx_mu_xcr_rmw(priv, IMX_MU_RCR, 0, IMX_MU_xCR_RIEn(priv->dcfg->type, cp->idx)); imx_mu_specific_rx() imx_mu_xcr_rmw(priv, IMX_MU_RCR, IMX_MU_xCR_RIEn(priv->dcfg->type, 0), 0); free_irq() The RX event remains enabled because in this short window the RX event was disabled in ->shutdown() while the interrupt was active and then enabled again by the ISR while ->shutdown waited in free_irq(). This race requires timing and if happens can be problematic on shared handlers if the "removed" channel triggers an interrupt. In this case the irq-core will shutdown the interrupt with the "nobody cared" message. Introduce imx_mu_con_priv::shutdown to signal that the channel is shutting down. This flag is set with the lock held (by imx_mu_xcr_clr_shut()). The unmask side uses imx_mu_xcr_set_act() which only enables the event if the channel has not been shutdown and serialises on the same lock.

Affected packages

Ecosystem Package Introduced Fixed