CVE-2026-90244: iommu/dma: Restore locking around msi_page_list
In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Restore locking around msipagelist
Unlike a group's default domain, which is always freshly allocated and privately owned (iommugroupallocdefaultdomain()), VFIO type1's legacy container merges any newly attached group into an existing domain whenever their iommuops and cache-coherency enforcement match.
iommudmagetmsipage() only asserts the caller's own group mutex is held (iommugroupmutexassert()). On an IOMMU that publishes IOMMURESVSWMSI, 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 VFIODEVICESETIRQS lands on a different device fd and group mutex, but both devices' domains are the same merged domain, so both can enter iommudmagetmsipage() concurrently and corrupt msipagelist.
commit 288683c92b1a ("iommu: Make iommudmapreparemsi() into a generic operation") dropped the prior msipreparelock on the reasoning that "each iommudomain 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 (iommufdswmapmsi()) take a ctx-wide swmsilock before ever reaching the shared list. VFIO type1 can't mirror that since it dispatches to iommudmaswmsi() which is outside VFIO's jurisdiction.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Exposure requires VFIO type1's legacy container to merge multiple assigned groups into the same IOMMU domain, with matching IOMMU operations and cache-coherency enforcement. The IOMMU must publish IOMMU_RESV_SW_MSI; ARM SMMU is given as an example.
What activity is needed to trigger the issue?
A VM needs two qualifying devices assigned through the legacy container, with guest drivers probing and allocating MSIs in parallel. Concurrent host-side VFIO_DEVICE_SET_IRQS operations then enter iommu_dma_get_msi_page() through different group mutexes while sharing one domain.
What is the impact of a successful trigger?
The concurrent accesses can corrupt the shared IOMMU domain's msi_page_list. The restored static lock serializes this access.
Is the normal per-group default-domain configuration affected?
The description states that a group's default domain is freshly allocated and privately owned, so the assumption of one domain per group holds there. The affected case is the VFIO type1 legacy-container behavior that merges groups into an existing domain.