CVE-2026-45944

What it actually does

This is a Linux kernel Intel VT-d/IOMMU race condition in context-entry teardown. The vulnerable code clears a 128-bit VT-d context entry using multiple 64-bit writes, which can briefly leave a partially updated, inconsistent entry visible to IOMMU hardware while the Present bit remains set. If the IOMMU fetches or uses that torn entry, it can trigger unpredictable DMA-remapping behavior, spurious IOMMU faults, or potentially incorrect device-to-memory translation state. The issue is local, high-complexity, and requires high privileges because exploitation depends on the ability to influence device/IOMMU context lifecycle, typically through kernel-level, driver-level, virtualization, or privileged device-management paths. The fix changes the ordering so the Present bit is cleared first, uses appropriate DMA write barriers, invalidates relevant caches, and only then zeros the full entry; it also ensures entries are fully initialized before being marked present.

Why it matters to the business

Systems using affected Linux kernel versions with Intel VT-d/IOMMU enabled may experience instability, device malfunction, virtualization disruption, or loss of isolation guarantees under rare timing conditions. In environments relying on PCI passthrough, SR-IOV, VFIO, containers with device access, or hypervisor workloads, the operational impact can include VM crashes, host instability, data corruption risk, or security boundary weakening between devices and memory. The CVSS score is high, but practical exploitation is constrained by local access, high privileges, and high timing complexity; EPSS is very low and there is no known CISA KEV listing or ransomware association, so remediation should be prioritized through standard kernel patch cycles rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker would first need privileged local access or equivalent control over a path that can repeatedly create, modify, or tear down IOMMU context entries, such as privileged device assignment, VFIO, PCI passthrough, driver manipulation, or kernel-adjacent management operations. They would then attempt to trigger rapid teardown and reconfiguration of device DMA-remapping contexts while the IOMMU hardware may still fetch the entry. In vulnerable kernels, the context entry can be partially zeroed while its Present bit is still visible, creating a narrow race window where hardware consumes inconsistent translation metadata. Successful exploitation would require precise timing and favorable hardware/software conditions and may manifest as IOMMU faults, device reset behavior, kernel warnings, denial of service, or potentially incorrect DMA mappings that affect confidentiality, integrity, or availability. There is currently no public exploit maturity indicated and no named threat actors reported for this issue.

How to fix it

Upgrade to a Linux kernel version that includes the VT-d/IOMMU fix for context-entry teardown ordering. Because no exact fixed package versions were provided, use the security advisories from the operating system or kernel vendor and deploy the first kernel build that contains the patch described as clearing the VT-d context-entry Present bit before teardown, adding dma_wmb() ordering, and performing context-cache invalidation before zeroing the entry. For distribution-managed systems, apply the latest vendor kernel security update rather than attempting a partial source patch. Reboot into the patched kernel after installation; simply installing the package is insufficient if the old kernel remains running. Where immediate patching is not possible, reduce exposure by limiting privileged local access, restricting VFIO/PCI passthrough and SR-IOV administration to trusted operators, disabling unneeded device assignment features, avoiding untrusted workloads on hosts with device passthrough, and considering temporary disabling of IOMMU-dependent passthrough workflows if risk outweighs operational need.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor release containing the fix. Validate with commands such as `uname -r`, package-manager kernel inventory, and vendor advisory mapping. Review boot parameters and hardware capabilities to determine whether Intel VT-d/IOMMU is enabled, for example by checking `/proc/cmdline`, `dmesg`, and IOMMU group information under `/sys/kernel/iommu_groups/`. On source-based or custom kernels, verify the VT-d driver implements the corrected sequence: clear the Present bit first, issue a DMA write barrier, invalidate IOMMU/context caches, then zero the full context entry, and ensure context setup uses a barrier before setting Present. After rebooting, run representative workloads involving VFIO, PCI passthrough, SR-IOV, or device hotplug and check for absence of new DMAR/IOMMU faults, kernel warnings, or device reset events.

Typical attack path

1. Gain high-privilege local access to a Linux system, hypervisor host, or environment that can manage devices using Intel VT-d/IOMMU.
2. Identify that Intel VT-d/IOMMU is enabled and that the running kernel contains the vulnerable context-entry teardown behavior.
3. Use privileged device-management paths such as VFIO, PCI passthrough, SR-IOV, driver bind/unbind, or repeated device assignment operations to exercise context-entry teardown.
4. Repeatedly trigger teardown/reinitialization of IOMMU context entries to increase the chance of the hardware fetching a torn entry.
5. Attempt to convert resulting IOMMU faults or inconsistent translation state into host instability, device malfunction, denial of service, or unintended DMA access effects.
6. Cover tracks by blending activity with legitimate administrative or virtualization device-management operations.

How to detect it

There are no reliable application-layer indicators for exploitation because this is a low-level kernel/IOMMU race and successful triggering may look like hardware, driver, or virtualization instability. To investigate possible prior exploitation or attempted triggering, collect kernel logs and persistent journal data from affected hosts and look for unusual clusters of Intel VT-d/DMAR/IOMMU faults, device assignment churn, PCI reset events, VFIO errors, driver bind/unbind activity, VM crashes correlated with passthrough devices, or kernel warnings around DMA remapping. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, hypervisor management logs, libvirt/QEMU logs, audit logs for privileged device-management commands, and package/kernel update history. Pay particular attention to repeated sequences involving VFIO device attach/detach, PCI driver unbind/rebind, SR-IOV virtual function creation/removal, or passthrough VM start/stop operations immediately preceding IOMMU faults. Because exploitation requires high privileges, also review authentication and sudo/audit records for administrators or service accounts performing unusual hardware or virtualization management actions.

• DMAR:
• IOMMU fault
• DMAR: DRHD: handling fault status reg
• DMAR: [DMA Read]
• DMAR: [DMA Write]
• fault reason
• Present bit
• context entry
• context cache invalidation
• vfio-pci
• VFIO
• vfio:
• PCIe Bus Error
• AER: Corrected error
• AER: Uncorrected
• resetting device
• driver unbind
• driver bind
• /sys/bus/pci/drivers/vfio-pci/bind
• /sys/bus/pci/drivers/vfio-pci/unbind
• /sys/kernel/iommu_groups/
• qemu-system-x86_64
• libvirtd
• virtqemud

What your security team should do

• Prioritize patching hypervisors, bare-metal hosts, and systems using Intel VT-d with VFIO, PCI passthrough, SR-IOV, GPU/NIC passthrough, or other direct device assignment.
• Apply the latest vendor-supported kernel update and reboot hosts into the fixed kernel; verify the active kernel version after maintenance.
• Restrict administrative access to device-assignment, driver bind/unbind, and virtualization host management capabilities until patching is complete.
• Avoid running untrusted or multi-tenant workloads with direct device access on unpatched systems.
• Monitor kernel logs for DMAR, IOMMU, PCIe, VFIO, device reset, and machine-check anomalies that could indicate attempted triggering or operational impact.
• For custom kernels, backport the upstream fix rather than relying on compiler behavior or architecture write-ordering assumptions.
• Document systems where IOMMU is enabled and device passthrough is used so future IOMMU advisories can be triaged quickly.