CVE-2025-38062

What it actually does

Use-after-free on an IOMMU cookie pointer stored in msi_desc during a race between iommu_attach_group and iommu_dma_compose_msi_msg when an iommufd-backed VFIO domain is changed concurrently with MSI programming; a secondary unlocked iommu_get_domain_for_dev call is also affected.

Why it matters to the business

Attackers with access to a VFIO-managed device can trigger kernel memory corruption on affected Linux systems, leading to denial of service, privilege escalation, or arbitrary code execution; the bug affects virtualized and containerized workloads using iommufd, increasing operational risk for cloud and enterprise hosts until patched.

How an attack unfolds

An attacker controlling a userspace VFIO client races VFIO_DEVICE_ATTACH_IOMMUFD_PT against VFIO_DEVICE_SET_IRQS while an MSI interrupt is being programmed; the freed cookie pointer and domain reference are dereferenced without locking, resulting in use-after-free. Named threat actors and related Linux kernel privilege-escalation campaigns have demonstrated similar patterns against unpatched kernels.

How to fix it

Upgrade the Linux kernel to commit e4d3763223c7b72ded53425207075e7453b4e3d5 or later; apply the companion fix in "iommu: Make iommu_dma_prepare_msi() into a generic operation"; rebuild and reboot all affected hosts. Where immediate patching is impossible, restrict VFIO/iommufd usage to trusted workloads and monitor for domain-change operations.

How to confirm the fix worked

Verify the running kernel contains commit e4d3763223c7b72ded53425207075e7453b4e3d5; confirm iommu_dma_prepare_msi no longer stores a cookie pointer; exercise VFIO attach/set-irqs concurrently under stress and ensure no UAF reports appear in dmesg or KASAN logs.

Typical attack path

1. Obtain a VFIO device file descriptor for a device backed by iommufd
2. Prepare an MSI interrupt allocation via VFIO_DEVICE_SET_IRQS
3. Concurrently issue VFIO_DEVICE_ATTACH_IOMMUFD_PT to change the IOMMU domain
4. Trigger the race window so that the stale cookie pointer and unlocked domain lookup are dereferenced
5. Exploit the resulting use-after-free for memory corruption or code execution

How to detect it

Search kernel logs and audit trails for concurrent VFIO attach and IRQ programming events; inspect for KASAN or slab UAF reports mentioning msi_desc or iommu_dma_compose_msi_msg; correlate with process activity using VFIO_DEVICE_ATTACH_IOMMUFD_PT or VFIO_DEVICE_SET_IRQS ioctls.

What your security team should do

• Prioritize kernel upgrades on all systems exposing VFIO or iommufd to untrusted guests
• Add the fixed commit to internal kernel build pipelines and CI regression tests
• Restrict VFIO device access via SELinux/AppArmor or device-allow lists until patches are deployed
• Monitor EPSS trend and threat-actor activity for any increase in targeting of similar IOMMU races