CVE Catalog

CVE-2026-90244

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.16%

6th percentile - higher than 6% of all known CVEs

Summary

A locking issue exists in the Linux kernel's iommu/dma subsystem around the msi_page_list. When multiple devices assigned to a VM via the legacy VFIO type1 container share the same IOMMU domain (e.g. ARM SMMU with IOMMU_RESV_SW_MSI), concurrent calls to iommu_dma_get_msi_page() can corrupt that list. The fix restores the static msi_prepare_lock.

Risk Assessment

Concurrent MSI handling by multiple VFIO devices can corrupt kernel memory, leading to system instability or potential code execution. This mainly affects virtualization environments with assigned devices on IOMMUs that publish IOMMU_RESV_SW_MSI.

Recommendation

Update the Linux kernel to a version containing the fix that restores the msi_prepare_lock. If updating is not possible, avoid assigning multiple MSI-capable devices to the same VM through the legacy VFIO type1 container.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS