FKIE_CVE-2026-23361
Vulnerability from fkie_nvd - Published: 2026-03-25 11:16 - Updated: 2026-04-24 18:41
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry
Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X
interrupt to the host using a writel(), which generates a PCI posted write
transaction. There's no completion for posted writes, so the writel() may
return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also
unmaps the outbound ATU entry used for the PCI write, so the write races
with the unmap.
If the PCI write loses the race with the ATU unmap, the write may corrupt
host memory or cause IOMMU errors, e.g., these when running fio with a
larger queue depth against nvmet-pci-epf:
arm-smmu-v3 fc900000.iommu: 0x0000010000000010
arm-smmu-v3 fc900000.iommu: 0x0000020000000000
arm-smmu-v3 fc900000.iommu: 0x000000090000f040
arm-smmu-v3 fc900000.iommu: 0x0000000000000000
arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0
arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0
Flush the write by performing a readl() of the same address to ensure that
the write has reached the destination before the ATU entry is unmapped.
The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit
8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there
it was solved by dedicating an outbound iATU only for MSI. We can't do the
same for MSI-X because each vector can have a different msg_addr and the
msg_addr may be changed while the vector is masked.
[bhelgaas: commit log]
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 4.19 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 | |
| linux | linux_kernel | 7.0 |
{
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9CC70BD7-E7C9-4802-B345-09DF8AE28044",
"versionEndExcluding": "6.12.77",
"versionStartIncluding": "4.19.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A5E006E4-59C7-43C1-9231-62A72219F2BA",
"versionEndExcluding": "6.18.17",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "69245D10-0B71-485E-80C3-A64F077004D3",
"versionEndExcluding": "6.19.7",
"versionStartIncluding": "6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:4.19:-:*:*:*:*:*:*",
"matchCriteriaId": "CFDAD450-8799-4C2D-80CE-2AA45DEC35CE",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
"matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*",
"matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*",
"matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*",
"matchCriteriaId": "58A9FEFF-C040-420D-8F0A-BFDAAA1DF258",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*",
"matchCriteriaId": "1D2315C0-D46F-4F85-9754-F9E5E11374A6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:*",
"matchCriteriaId": "512EE3A8-A590-4501-9A94-5D4B268D6138",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry\n\nEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X\ninterrupt to the host using a writel(), which generates a PCI posted write\ntransaction. There\u0027s no completion for posted writes, so the writel() may\nreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() also\nunmaps the outbound ATU entry used for the PCI write, so the write races\nwith the unmap.\n\nIf the PCI write loses the race with the ATU unmap, the write may corrupt\nhost memory or cause IOMMU errors, e.g., these when running fio with a\nlarger queue depth against nvmet-pci-epf:\n\n arm-smmu-v3 fc900000.iommu: 0x0000010000000010\n arm-smmu-v3 fc900000.iommu: 0x0000020000000000\n arm-smmu-v3 fc900000.iommu: 0x000000090000f040\n arm-smmu-v3 fc900000.iommu: 0x0000000000000000\n arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0\n arm-smmu-v3 fc900000.iommu: unpriv data write s1 \"Input address caused fault\" stag: 0x0\n\nFlush the write by performing a readl() of the same address to ensure that\nthe write has reached the destination before the ATU entry is unmapped.\n\nThe same problem was solved for dw_pcie_ep_raise_msi_irq() in commit\n8719c64e76bf (\"PCI: dwc: ep: Cache MSI outbound iATU mapping\"), but there\nit was solved by dedicating an outbound iATU only for MSI. We can\u0027t do the\nsame for MSI-X because each vector can have a different msg_addr and the\nmsg_addr may be changed while the vector is masked.\n\n[bhelgaas: commit log]"
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nPCI: dwc: ep: Vaciar escritura MSI-X antes de desmapear su entrada ATU\n\nLos controladores de punto final usan dw_pcie_ep_raise_msix_irq() para generar una interrupci\u00f3n MSI-X al host usando un writel(), lo que genera una transacci\u00f3n de escritura publicada PCI. No hay finalizaci\u00f3n para las escrituras publicadas, por lo que el writel() puede regresar antes de que la escritura PCI se complete. dw_pcie_ep_raise_msix_irq() tambi\u00e9n desmapea la entrada ATU de salida usada para la escritura PCI, por lo que la escritura compite con el desmapeo.\n\nSi la escritura PCI pierde la carrera con el desmapeo ATU, la escritura puede corromper la memoria del host o causar errores de IOMMU, por ejemplo, estos al ejecutar fio con una profundidad de cola mayor contra nvmet-pci-epf:\n\n arm-smmu-v3 fc900000.iommu: 0x0000010000000010\n arm-smmu-v3 fc900000.iommu: 0x0000020000000000\n arm-smmu-v3 fc900000.iommu: 0x000000090000f040\n arm-smmu-v3 fc900000.iommu: 0x0000000000000000\n arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION cliente: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0\n arm-smmu-v3 fc900000.iommu: unpriv data write s1 \u0027Input address caused fault\u0027 stag: 0x0\n\nVaciar la escritura realizando un readl() de la misma direcci\u00f3n para asegurar que la escritura ha alcanzado el destino antes de que la entrada ATU sea desmapeada.\n\nEl mismo problema fue resuelto para dw_pcie_ep_raise_msi_irq() en el commit 8719c64e76bf (\u0027PCI: dwc: ep: Cacheo de mapeo iATU de salida MSI\u0027), pero all\u00ed fue resuelto dedicando un iATU de salida solo para MSI. No podemos hacer lo mismo para MSI-X porque cada vector puede tener una msg_addr diferente y la msg_addr puede ser cambiada mientras el vector est\u00e1 enmascarado.\n\n[bhelgaas: registro de commit]"
}
],
"id": "CVE-2026-23361",
"lastModified": "2026-04-24T18:41:30.110",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2026-03-25T11:16:35.060",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6f60a783860c77b309f7d81003b6a0c73feca49e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a7afb8f810c04845fdfc58c57d9cf0cc5f23ced0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c22533c66ccae10511ad6a7afc34bb26c47577e3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/eaa6a56801ddd2d9b4980f19e7fe002b00994804"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…