CVE-2026-90332
High · 8.2CVSS
8.2
EPSS
0.3%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A missing flush step in low-level hardware interrupt handling can cause some device notifications to be lost, potentially disrupting connected hardware.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The MSI path in the DesignWare PCIe endpoint driver unmaps an iATU entry for a cached MSI address without first draining posted writes, allowing those writes to be dropped or misrouted when the Root Complex later changes the target address.
Why it matters to the business
PCI endpoint devices may silently lose interrupts, leading to device timeouts, communication failures, or degraded hardware functionality in affected systems.
How an attack unfolds
An attacker able to influence the Root Complex MSI address observed by the endpoint triggers dw_pcie_ep_raise_msi_irq after an address change; the driver tears down the iATU mapping while a prior MSI write remains posted in the fabric, causing the write to be lost.
How to fix it
Apply the upstream fix that performs a readback from the mapped MSI window before unmapping the iATU entry in dw_pcie_ep_raise_msi_irq, matching the existing MSI-X behavior.
How to confirm the fix worked
Inspect the dw_pcie_ep_raise_msi_irq implementation for the added readback flush prior to iATU unmap and confirm the change is present in running kernel sources or binaries.
Typical attack path
- Modify MSI target address visible to the endpoint driver
- Trigger an MSI-raising operation that uses the stale cached address
- Force unmapping of the iATU entry before the posted write completes
- Observe dropped or misrouted interrupt at the Root Complex
How to detect it
Review kernel logs for PCI endpoint MSI-related warnings or device communication failures around the time of address reconfiguration events; examine PCIe endpoint driver traces for unmap operations without preceding flush reads.
What your security team should do
- Prioritize kernel updates containing the MSI flush fix on all systems using DesignWare PCIe endpoint controllers
- Monitor vendor advisories for backported patches in supported distributions
- Test interrupt-driven device functionality after applying updates to verify stability
The record
In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush cached MSI write before unmapping the iATU The MSI-X path already flushes any posted MSI-X write before tearing down its iATU mapping. That was added by commit c22533c66cca ("PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry") to make sure the write reaches the Root Complex before the outbound window that translates it disappears. The MSI path has the same problem but no equivalent flush. When the Endpoint driver caches an MSI target address and later observes that the Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing iATU entry and reprograms it for the new address. Between the last MSI writel() and the unmap there may still be a posted write sitting in the fabric, and unmapping the iATU entry can drop or misroute that write. Fix this by reading back from the mapped MSI window before the unmap. The readback drains any posted MSI writes through the same iATU entry that mapped them, which is the same logic the MSI-X path uses. [mani: commit log]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|