Look up another CVE · open CVE-2026-90332 in the interactive tracker
CVE-2026-90332
PCI: dwc: ep: Flush cached MSI write before unmapping the iATU
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/pci. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90332 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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]
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/pci/controller/dwc/pcie-designware-ep.c
drivers/pci/controller/dwc/pcie-designware.h
- What this is
- PCI DRIVER FOR SYNOPSYS DESIGNWAREMAINTAINERS section matched on drivers/pci/controller/dwc/*designware* · linux-pci@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_PCIE_DW_EP /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixieYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- n
- not enabled on any flavour - this release does not build the code
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_PCIE_DW_EP
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 8.2 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.27%, higher than 17.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/pci
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.0 | 7.2.6 | 914704c7b318 |
| 7.0 | 7.3 | 1b01d725d8b4 |
| 6.19.7 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- dw_pcie_ep_raise_msi_irq() unmaps when DBI PCI_MSI_ADDRESS_LO/HI (programmed by a Root Complex CfgWr) no longer matches ep->msi_msg_addr; the following raise is pci_epc_raise_irq() from nvmet_pci_epf_raise_irq() after an NVMe CQ post or pci_epf_test_cmd_handler() on COMMAND_RAISE_MSI_IRQ, i.e. MMIO from a connected PCIe peer, not routed IP and not an EP-local syscall.
- AC:LAttack complexity, low
- The RC can CfgWr a new Message Address and immediately doorbell another NVMe command or COMMAND_RAISE_MSI_IRQ so the next dw_pcie_ep_raise_msi_irq() takes the unmap path; both the address change and the IRQ-raising traffic are attacker-driven, and the same in-flight posted write was hit with fio against nvmet-pci-epf on the MSI-X path.
- PR:NPrivileges required, none
- CfgWr to the MSI capability is applied in hardware to DBI with no EP Linux uid or capability check, and nvmet_pci_epf_cq_work()/pci_epf_test_cmd_handler() honor host doorbells and BAR commands without authentication on the endpoint.
- UI:NUser interaction, none
- nvmet_pci_epf_cq_work() and pci_epf_test_cmd_handler() run from endpoint workqueues solely in response to host MMIO; no operator on the EP must mount a filesystem or open a device node to reach dw_pcie_ep_raise_msi_irq().
- S:CScope, changed
- dw_pcie_ep_unmap_addr() clears the outbound iATU window that translates the MSI writel into a host Memory Write; a posted write that loses that race can be misrouted off the host MSI doorbell page (the MSI-X sibling documented host memory corruption and arm-smmu-v3 F_TRANSLATION), crossing the EP-to-host DMA translation boundary.
- C:NConfidentiality impact, none
- The in-flight operation is writel(msg_data | (interrupt_num-1), ep->msi_mem + offset), a 32-bit posted MSI doorbell store; the bug does not read EP kernel memory or host buffers.
- I:LIntegrity impact, low
- A misrouted MSI writel can store 32 bits of (PCI_MSI_DATA_* | vector) through a torn outbound iATU into host memory, which is a limited modification, not an arbitrary EP-kernel write or control-flow hijack.
- A:HAvailability impact, high
- Dropping the posted MSI write loses the host interrupt, and this function's comment states that reprogramming iATU with AXI operations in flight is unsafe, which can stall dw_pcie_ep_map_addr()/writel() on the outbound bridge; the MSI-X counterpart produced arm-smmu-v3 F_TRANSLATION under nvmet-pci-epf fio, denying further MSI delivery until reset.