Answer in brief
CVE-2026-90244 records a High severity (CVSS 7.8) vulnerability in iommu/dma: Restore locking around msi_page_list. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=288683c92b1abc32277c83819bea287af614d239 <e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2 || >=288683c92b1abc32277c83819bea287af614d239 <2af1e99ec14d226d66ceb9f16c663ee2568e6676 || >=288683c92b1abc32277c83819bea287af614d239 <5a9e89ea34e0e34ac5d7e949042d665533549e40 | e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2, 2af1e99ec14d226d66ceb9f16c663ee2568e6676, 5a9e89ea34e0e34ac5d7e949042d665533549e40 |
| Linux/Linuxgeneric | 6.15 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Restore locking around msi_page_list Unlike a group's default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommu_ops and cache-coherency enforcement match. iommu_dma_get_msi_page() only asserts the caller's own group mutex is held (iommu_group_mutex_assert()). On an IOMMU that publishes IOMMU_RESV_SW_MSI, e.g. ARM SMMU, a VM with two such devices assigned through the legacy container can have their guest drivers probe and allocate MSIs in parallel; each host-side VFIO_DEVICE_SET_IRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommu_dma_get_msi_page() concurrently and corrupt msi_page_list. commit 288683c92b1a ("iommu: Make iommu_dma_prepare_msi() into a generic operation") dropped the prior msi_prepare_lock on the reasoning that "each iommu_domain is unique to a group," which holds for default domains but not this VFIO type1 case. Restore the static lock, since it's only guarding a corner case and will likely never be contended. iommufd avoids the equivalent problem by having its own callers (iommufd_sw_map_msi()) take a ctx-wide sw_msi_lock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIO's jurisdiction.
Quoted source text, attributed separately from HOL analysis.