Cloudanix VulnDB

CVE-2026-90244

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in the Linux kernel can let specially configured virtual machines corrupt memory when they use certain hardware passthrough features, potentially crashing the host or allowing an attacker with local access to gain more privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in iommu_dma_get_msi_page() permits concurrent modification of the shared msi_page_list when VFIO type1 legacy containers merge multiple groups into one domain on IOMMU_RESV_SW_MSI hardware, bypassing the single-group mutex assertion.

Why it matters to the business

Kernel memory corruption on Linux systems exposing VFIO device assignment to virtual machines can cause crashes, denial of service, or local privilege escalation; the issue is limited to uncommon multi-device legacy container configurations and carries low immediate operational risk.

How an attack unfolds

An attacker with local access provisions a VM containing two devices that share an IOMMU domain through a VFIO type1 legacy container, then triggers parallel guest driver MSI allocation; each VFIO_DEVICE_SET_IRQS call holds only its own group mutex, allowing simultaneous entry into the unprotected list manipulation code and resulting corruption.

How to fix it

Apply the upstream fix that restores the static msi_prepare_lock around msi_page_list access; rebuild and deploy the patched kernel, then reboot affected hosts. Prefer iommufd-based device assignment where possible to avoid the legacy container path.

How to confirm the fix worked

Inspect the running kernel source or symbols for the restored static lock protecting msi_page_list; confirm absence of parallel MSI allocation paths in VFIO type1 merged domains through code review or targeted stress testing with multiple devices.

Typical attack path

  1. Obtain local access on a Linux host using VFIO with IOMMU_RESV_SW_MSI hardware such as ARM SMMU
  2. Create a VM and assign two compatible devices via the legacy VFIO type1 container
  3. Boot guest drivers that probe and allocate MSIs concurrently on both devices
  4. Trigger iommu_dma_get_msi_page() calls that race on the merged domain's msi_page_list
  5. Exploit resulting memory corruption for crash or escalation

How to detect it

Review kernel logs for IOMMU or VFIO related warnings and oopses during device assignment or MSI allocation; look for evidence of concurrent MSI setup on shared domains in system call traces or ftrace captures of iommu_dma_sw_msi paths.

What your security team should do

  • Patch and reboot all Linux hosts using VFIO device assignment within the next maintenance window
  • Audit VFIO configurations and migrate legacy type1 containers to iommufd where feasible
  • Monitor kernel bug-fix releases for IOMMU and VFIO changes
  • Restrict local access to hosts performing device passthrough until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed