iommu/dma: Restore locking around msi_page_list

Answer in brief

CVE-2026-90244 records a Unknown severity 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.

Published Sep 17, 2026Updated Sep 17, 2026Source checked Sep 17, 2026First seen by HOL Sep 17, 2026Material review Sep 17, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. 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.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=288683c92b1abc32277c83819bea287af614d239 <e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2 \|\| >=288683c92b1abc32277c83819bea287af614d239 <2af1e99ec14d226d66ceb9f16c663ee2568e6676 \|\| >=288683c92b1abc32277c83819bea287af614d239 <5a9e89ea34e0e34ac5d7e949042d665533549e40	e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2, 2af1e99ec14d226d66ceb9f16c663ee2568e6676, 5a9e89ea34e0e34ac5d7e949042d665533549e40
Linux/Linuxgeneric	6.15	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Sep 17, 2026

Sources and claim methodology

Upstream source description

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.