CVE-2026-90244

In the Linux kernel, the following vulnerability has been resolved:

iommu/dma: Restore locking around msi_page_list

Unlike a groups default domain, which is always freshly allocated and privately owned (iommu_group_alloc_default_domain()), VFIO type1s 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 callers 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 its 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 cant mirror that since it dispatches to iommu_dma_sw_msi() which is outside VFIOs jurisdiction.

Affected Software

References

• https://git.kernel.org/stable/c/2af1e99ec14d226d66ceb9f16c663ee2568e6676
• https://git.kernel.org/stable/c/5a9e89ea34e0e34ac5d7e949042d665533549e40
• https://git.kernel.org/stable/c/e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2