CVE-2026-90244

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…

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.