A newly disclosed vulnerability in the Linux kernel’s Intel VT-d IOMMU driver could let hardware momentarily see a partially destroyed memory-access structure, potentially causing system instability or worse in virtualized environments. The fix, tracked as CVE-2026-45944, landed in stable kernel releases on May 27, 2026, and forces the driver to revoke a critical “Present” flag before tearing down context entries—closing a race window that had existed since kernel 2.6.24.

What actually changed

The bug resided in how the kernel tears down a 128‑bit IOMMU context entry, the structure that tells Intel’s hardware how to translate and restrict direct memory access (DMA) from devices. Previously, the driver simply zeroed the entire entry with multiple 64‑bit writes. That created a fleeting moment where some fields were already cleared but the Present bit—the hardware’s signal that the entry is valid—remained set. If the IOMMU fetched the entry during that torn state, it could act on a malformed configuration, leading to “unpredictable behavior or spurious faults,” according to the kernel.org advisory.

The root cause wasn’t just x86 memory ordering. Though x86 strongly orders stores, the compiler can reorder the two 64‑bit halves, and even without that, the IOMMU itself doesn’t guarantee atomic fetches of the entire 128‑bit entry across separate CPU writes. The fix realigns the driver with the VT‑d specification’s “Guidance to Software for Invalidations” (Section 6.5.3.3). Now, the teardown sequence first clears only the Present bit, then issues a DMA write barrier (dma_wmb()) to make that change visible to the IOMMU, performs required cache invalidations, and only then zero‑fills the remaining fields. A matching barrier was added to context_set_present() so that a new entry is fully initialized before its Present bit lights up.

The fix applies to three code paths: the main context‑entry teardown in intel_iommu.c, the PASID context management in pasid.c, and the header iommu.h. Affected kernels range from all 2.6.24+ releases up to but not including 6.18.14, and the 6.19.x series before 6.19.4. Linux 7.0 also contains the fix at its original commit.

What it means for you

The practical risk depends heavily on how you use VT‑d.

Desktop and casual Linux users are unlikely to see any symptoms. The bug doesn’t offer a trivial local privilege escalation; exploiting it requires a local attacker with high privileges, a highly specific timing window, and a workload that rapidly churns through device mappings. The CVSS 3.1 base score from kernel.org is 7.5 (High), but with a vector of AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H—meaning local access, high attack complexity, and high privileges needed. If you run a single GPU, a couple of NVMe drives, and no virtual machines that hot‑plug PCIe devices, the race window practically never opens.

Virtualization hosts and VFIO passthrough setups face a starker story. Hypervisors that assign physical devices to guests, container hosts that enforce per‑container DMA isolation, and any server that repeatedly creates or destroys device mappings are constantly exercising the vulnerable code. A torn context entry could corrupt memory isolation, crash the host, or—in a worst‑case scenario—let a device read or write memory outside its assigned domain. Even without a weaponized exploit, the flakiness can manifest as DMAR faults, mysterious passthrough failures, or random kernel panics during VM migrations or device resets.

Windows users indirectly affected will find the fix on the Linux side. Many Windows pros run Linux hypervisors (KVM, Proxmox, or custom Xen setups) to host Windows VMs, especially for GPU passthrough gaming or workstation workloads. If your Linux host kernel is unpatched, your Windows guests are only as sandboxed as the IOMMU allows—and the bug subverts that boundary at the exact moment a device is being torn down or reassigned. No Windows update can fix this; the remediation target is the host kernel.

Enterprise and cloud operators should treat this as a high‑priority correctness update for any Linux host that enables VT‑d. The more your fleet relies on hardware‑enforced device isolation—for tenant separation, confidential computing, or secure DMA—the more you depend on a bug‑free IOMMU. Even without a proven exploit, the possibility of data leaks or denial‑of‑service across trust boundaries makes it a patch‑now situation for multi‑tenant environments.

How we got here

The vulnerable code dates back to the introduction of Intel IOMMU support in kernel 2.6.24 (2008). For nearly two decades, the teardown path simply memset the context entry to zero, a shortcut that felt safe because modern x86 CPUs enforce strong write ordering for writes to the same cache line. But the context entry is 128 bits wide, spanning two 64‑bit words. CPU write ordering only guarantees that stores from a single core become visible to other cores in program order; it doesn’t force the IOMMU to observe the 128‑bit update as a single, indivisible operation.

The real villain, however, is the compiler. Even on x86, GCC or Clang can reorder the two 64‑bit writes if they appear independent—and to a compiler, writing the two halves of a struct is just two assignments. The resulting assembly could clear field A, then field B, and then set the Present bit to 0, exactly the opposite of what hardware expects. The kernel’s dma_wmb() barrier is the fix because it prevents the compiler from reordering stores and also ensures the write‑combining and caching behavior needed for DMA‑visible memory.

Intel’s VT‑d spec has long recommended this “Present‑bit‑first” handshake, but the kernel driver didn’t implement it until now. Why? Likely because the race was considered vanishingly rare and difficult to trigger, and the penalty of an extra barrier and invalidation cycle seemed wasteful on code paths that could fire thousands of times per second. But as virtualization density increased and devices grew faster, the window widened enough to be noticed. The fix was authored by Lu Baolu of Intel, a regular IOMMU contributor, and appeared on the linux‑iommu list in January 2026 before being merged into mainline and stable kernels in May.

What to do now

  1. Check your kernel version. Run uname -r. If you’re on a series older than 6.18, or between 6.19 and 6.19.3, you’re vulnerable. Desktop distributions with rolling releases (e.g., Arch, openSUSE Tumbleweed) likely already ship a fixed kernel; LTS distros (Ubuntu, RHEL, Debian) will backport the patch to their supported kernels without necessarily bumping the main version number. Look for the commit IDs in your distribution’s changelog: d2138abc8f0a, a922dbafb4a6, or c1e4f1dccbe9.
  2. Update your host kernel, not your guests. This is a Linux host‑side vulnerability; updating Windows virtual machines does nothing. If you run a cloud provider’s managed hypervisor, verify with your provider that they’ve applied the patch.
  3. Reboot into the new kernel. Kernel updates aren’t active until you restart. Use kexec or orchestrated reboots for production hosts. After reboot, confirm with `dmesg | grep