Linux kernel (drivers/pci/controller/dwc): Raising an MSI-X interrupt is a posted PCI write, and the endpoint driver

Impact

Raising an MSI-X interrupt is a posted PCI write, and the endpoint driver tears down the outbound address-translation entry that write depends on before the write has landed. If the write loses the race it is delivered through a stale or reassigned translation - the upstream commit states plainly that it may corrupt host memory, and the reporter's SMMU logs show the resulting unauthorised writes being caught as translation faults. That is a device writing into memory it was never given.

Who can reach it

Applies to a machine running Linux in PCIe *endpoint* mode - a DPU, smart storage appliance or nvmet-pci-epf target built on a DesignWare endpoint controller - not to a normal GPU compute node. The victim is the host on the other side of the link: the endpoint's misdirected DMA lands in host memory. It is driven by ordinary traffic, not by a special request - the reporter hit it with fio at high queue depth against nvmet-pci-epf, so any busy client of that endpoint makes it fire. Whether it is exploitable rather than merely corrupting depends on what the stale translation points at; an IOMMU on the host side turns most instances into faults rather than writes.

What to do

On any PCIe-endpoint-mode Linux appliance in the fleet, boot a kernel where dw_pcie_ep_raise_msix_irq() reads back the MSI-X address to flush the posted write before unmapping the ATU entry. Interim: keep an IOMMU enabled and enforcing on the host side of every such link so a misdirected endpoint write faults instead of landing, and avoid MSI-X on affected endpoint firmware where MSI is a workable substitute.

References