CVE-2026-90244

Status: UPDATED  |  Advisory ID: CVE-2026-90244

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References