{"api_version":"1","generated_at":"2026-09-19T08:40:31+00:00","cve":"CVE-2026-90332","urls":{"html":"https://cve.report/CVE-2026-90332","api":"https://cve.report/api/cve/CVE-2026-90332.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-90332","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-90332"},"summary":{"title":"PCI: dwc: ep: Flush cached MSI write before unmapping the iATU","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Flush cached MSI write before unmapping the iATU\n\nThe MSI-X path already flushes any posted MSI-X write before tearing down\nits iATU mapping. That was added by commit c22533c66cca (\"PCI: dwc: ep:\nFlush MSI-X write before unmapping its ATU entry\") to make sure the write\nreaches the Root Complex before the outbound window that translates it\ndisappears.\n\nThe MSI path has the same problem but no equivalent flush. When the\nEndpoint driver caches an MSI target address and later observes that the\nRoot Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing\niATU entry and reprograms it for the new address. Between the last MSI\nwritel() and the unmap there may still be a posted write sitting in the\nfabric, and unmapping the iATU entry can drop or misroute that write.\n\nFix this by reading back from the mapped MSI window before the unmap. The\nreadback drains any posted MSI writes through the same iATU entry that\nmapped them, which is the same logic the MSI-X path uses.\n\n[mani: commit log]","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-17 17:17:31","updated_at":"2026-09-18 18:17:54"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"8.2","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","baseScore":8.2,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"NONE","integrityImpact":"LOW","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"8.2","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","data":{"baseScore":8.2,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/1b01d725d8b42450b86a857bab3c46856c740166","name":"https://git.kernel.org/stable/c/1b01d725d8b42450b86a857bab3c46856c740166","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/914704c7b318bdaa42dce4e55f6c492190fee3b5","name":"https://git.kernel.org/stable/c/914704c7b318bdaa42dce4e55f6c492190fee3b5","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-90332","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90332","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 468711a40d5dfc01bf0a24c1981246a2c93ac405 914704c7b318bdaa42dce4e55f6c492190fee3b5 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 468711a40d5dfc01bf0a24c1981246a2c93ac405 1b01d725d8b42450b86a857bab3c46856c740166 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected cc83cd7b7d73d42ee64c7fc08ce679957df0f315 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.19.7 6.20 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.0","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.6 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"90332","cve":"CVE-2026-90332","epss":"0.002100000","percentile":"0.115780000","score_date":"2026-09-18","updated_at":"2026-09-19 00:06:16"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["drivers/pci/controller/dwc/pcie-designware-ep.c","drivers/pci/controller/dwc/pcie-designware.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"914704c7b318bdaa42dce4e55f6c492190fee3b5","status":"affected","version":"468711a40d5dfc01bf0a24c1981246a2c93ac405","versionType":"git"},{"lessThan":"1b01d725d8b42450b86a857bab3c46856c740166","status":"affected","version":"468711a40d5dfc01bf0a24c1981246a2c93ac405","versionType":"git"},{"status":"affected","version":"cc83cd7b7d73d42ee64c7fc08ce679957df0f315","versionType":"git"},{"lessThan":"6.20","status":"affected","version":"6.19.7","versionType":"semver"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["drivers/pci/controller/dwc/pcie-designware-ep.c","drivers/pci/controller/dwc/pcie-designware.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.0"},{"lessThan":"7.0","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.6","versionStartIncluding":"7.0","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"7.0","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19.7","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Flush cached MSI write before unmapping the iATU\n\nThe MSI-X path already flushes any posted MSI-X write before tearing down\nits iATU mapping. That was added by commit c22533c66cca (\"PCI: dwc: ep:\nFlush MSI-X write before unmapping its ATU entry\") to make sure the write\nreaches the Root Complex before the outbound window that translates it\ndisappears.\n\nThe MSI path has the same problem but no equivalent flush. When the\nEndpoint driver caches an MSI target address and later observes that the\nRoot Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing\niATU entry and reprograms it for the new address. Between the last MSI\nwritel() and the unmap there may still be a posted write sitting in the\nfabric, and unmapping the iATU entry can drop or misroute that write.\n\nFix this by reading back from the mapped MSI window before the unmap. The\nreadback drains any posted MSI writes through the same iATU entry that\nmapped them, which is the same logic the MSI-X path uses.\n\n[mani: commit log]"}],"metrics":[{"cvssV3_1":{"baseScore":8.2,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:A - 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.\nAC:L - 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.\nPR:N - 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.\nUI:N - 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().\nS:C - 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.\nC:N - 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.\nI:L - 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.\nA:H - 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."}]}],"providerMetadata":{"dateUpdated":"2026-09-18T17:54:42.618Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/914704c7b318bdaa42dce4e55f6c492190fee3b5"},{"url":"https://git.kernel.org/stable/c/1b01d725d8b42450b86a857bab3c46856c740166"}],"title":"PCI: dwc: ep: Flush cached MSI write before unmapping the iATU","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-90332","datePublished":"2026-09-17T16:08:46.154Z","dateReserved":"2026-09-11T19:38:34.803Z","dateUpdated":"2026-09-18T17:54:42.618Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-17 17:17:31","lastModifiedDate":"2026-09-18 18:17:54","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H","baseScore":8.2,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"NONE","integrityImpact":"LOW","availabilityImpact":"HIGH"},"exploitabilityScore":2.8,"impactScore":4.7}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90332","Ordinal":"1","Title":"PCI: dwc: ep: Flush cached MSI write before unmapping the iATU","CVE":"CVE-2026-90332","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90332","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Flush cached MSI write before unmapping the iATU\n\nThe MSI-X path already flushes any posted MSI-X write before tearing down\nits iATU mapping. That was added by commit c22533c66cca (\"PCI: dwc: ep:\nFlush MSI-X write before unmapping its ATU entry\") to make sure the write\nreaches the Root Complex before the outbound window that translates it\ndisappears.\n\nThe MSI path has the same problem but no equivalent flush. When the\nEndpoint driver caches an MSI target address and later observes that the\nRoot Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing\niATU entry and reprograms it for the new address. Between the last MSI\nwritel() and the unmap there may still be a posted write sitting in the\nfabric, and unmapping the iATU entry can drop or misroute that write.\n\nFix this by reading back from the mapped MSI window before the unmap. The\nreadback drains any posted MSI writes through the same iATU entry that\nmapped them, which is the same logic the MSI-X path uses.\n\n[mani: commit log]","Type":"Description","Title":"PCI: dwc: ep: Flush cached MSI write before unmapping the iATU"}]}}}