CVE-2026-45894

What it actually does

This is a race condition in the Linux kernel Intel VT-d IOMMU scalable-mode PASID handling path. During PASID entry teardown, the kernel previously zeroed the full 64-byte PASID table entry while the entry could still be marked Present. Because IOMMU hardware may read the entry in multiple internal transactions, hardware can observe a partially updated, inconsistent PASID entry. That can cause unpredictable IOMMU behavior, spurious DMA translation faults, device-TLB/IOTLB inconsistency, device disruption, kernel instability, or potentially incorrect DMA isolation behavior. The fix changes the teardown sequence to clear the Present bit first, enforce ordering with dma_wmb(), invalidate PASID/IOTLB/Device-TLB state, and only then clear the remaining PASID fields; it also ensures PASID setup publishes all fields before setting Present.

Why it matters to the business

Systems using affected Linux kernels on Intel VT-d scalable-mode IOMMU hardware may experience reliability and isolation failures under specific local conditions involving PASID-capable devices. The practical consequences can include host crashes, device failures, workload interruption, data corruption risk, or weakened DMA isolation between devices, processes, virtual machines, or accelerated workloads. The CVSS score is high, but exploitation is local, high-complexity, and there is no known public exploit or CISA KEV listing, so remediation should be prioritized for virtualization hosts, container/VM platforms, GPU/accelerator hosts, and systems using PCIe devices with PASID/SVA features rather than treated as broad internet-facing emergency exposure.

How an attack unfolds

An attacker would need local code execution with enough privileges or access to interact with PASID-capable hardware paths, such as through device assignment, accelerator/GPU use, virtualization, or other IOMMU-backed DMA workflows. The attacker attempts to repeatedly create, use, and tear down PASID contexts so that the CPU clears a PASID table entry while Intel VT-d hardware is concurrently fetching it. If the timing aligns, the IOMMU may consume a torn PASID entry containing a mixture of old and zeroed fields. Depending on hardware behavior and surrounding kernel state, this may produce DMA translation faults, device malfunction, denial of service, kernel crashes, or potentially incorrect DMA authorization. Exploitation is expected to be difficult and hardware/configuration dependent because it requires precise timing and a suitable PASID/IOMMU execution path.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Intel VT-d PASID teardown ordering issue. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution or kernel source branch and confirm the patch includes the PASID teardown sequence that clears the Present bit first, performs dma_wmb(), flushes PASID cache/IOTLB/Device-TLB state, and only then zeros the remaining PASID entry. Prioritize kernel updates on systems with Intel VT-d enabled, virtualization hosts, PCI passthrough/SR-IOV environments, GPU or accelerator servers, and hosts using Shared Virtual Addressing or PASID-capable devices. If immediate patching is not possible, reduce exposure by disabling untrusted local access to PASID-capable device features, limiting PCI passthrough/SR-IOV assignment to trusted workloads, disabling unused accelerator/GPU device access, and reviewing whether Intel IOMMU scalable-mode/PASID features are required for the workload. Avoid disabling IOMMU broadly unless explicitly approved, because doing so may reduce DMA protection and virtualization security.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or build includes the vendor fix for CVE-2026-45894 or the corresponding upstream commit. Validate that the host has rebooted into the fixed kernel, not merely installed it. On Linux systems, check the active kernel with uname -a and compare it against the distribution vendor’s fixed version. Review kernel source or vendor patch notes for changes in Intel VT-d PASID handling, particularly functions related to PASID entry teardown and setting the Present bit. Confirm whether affected exposure exists by checking for Intel IOMMU/VT-d enablement and PASID-capable devices using kernel boot logs, dmesg, lspci, and relevant virtualization or accelerator configuration. After patching, monitor dmesg or journal logs during PASID-capable device stress tests for recurring DMAR/IOMMU/PASID faults, device resets, or kernel warnings.

Typical attack path

1. Obtain local execution on a Linux system using an affected kernel and Intel VT-d scalable-mode IOMMU configuration.
2. Identify or access a PASID-capable device path, such as assigned PCIe hardware, accelerator/GPU functionality, SVA/IOPF-capable workflows, or virtualization-related DMA operations.
3. Repeatedly allocate, bind, use, and release PASID contexts to force frequent PASID entry setup and teardown.
4. Race the teardown operation so IOMMU hardware fetches the PASID entry while the CPU is clearing the entry fields.
5. Trigger inconsistent IOMMU state, causing DMA translation errors, device faults, host instability, or possible isolation failure.
6. Leverage resulting instability for denial of service or, if feasible on the target hardware and kernel configuration, attempt to influence DMA behavior across isolation boundaries.

How to detect it

There is no known public exploit and no reliable network-level indicator because exploitation is local and hardware/configuration dependent. To assess possible prior exploitation, review host-based telemetry from kernel logs, system journals, hypervisor logs, PCIe/AER logs, and device-driver logs on systems with Intel VT-d and PASID-capable hardware. Focus on unexplained bursts of DMAR or IOMMU faults, PASID-related errors, device-TLB/IOTLB invalidation messages, PCIe device resets, GPU/accelerator hangs, kernel warnings, oopses, panics, or host reboots that correlate with local user activity, VM lifecycle operations, PCI passthrough/SR-IOV events, accelerator workloads, or repeated device attach/detach operations. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, hypervisor management logs, crash dumps, kdump/vmcore artifacts, audit logs for device-node access, and EDR telemetry showing processes repeatedly opening or controlling PASID-capable device nodes. These artifacts are not definitive proof of exploitation, but repeated PASID/IOMMU faults on vulnerable kernels should trigger deeper forensic review.

• DMAR:
• IOMMU fault
• iommu fault
• PASID
• pasid
• IOTLB
• Device-TLB
• device TLB
• Intel-IOMMU
• intel-iommu
• Queued invalidation
• Invalidation timeout
• DMA Read NO_PASID
• DMA Write NO_PASID
• Present bit
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• kernel: DMAR
• kernel: IOMMU
• kernel: PASID
• AER: Corrected error
• AER: Uncorrected
• device reset
• GPU HANG
• NVRM: Xid
• amdgpu: GPU reset
• kernel BUG
• kernel panic
• Oops:
• BUG: unable to handle kernel
• general protection fault

What your security team should do

• Prioritize patching virtualization hosts, bare-metal cloud hosts, PCI passthrough/SR-IOV systems, GPU/accelerator servers, and other Linux systems using Intel VT-d with PASID-capable devices.
• Confirm the fixed kernel is both installed and actively running after reboot; kernel package installation alone is not sufficient.
• Inventory systems with Intel VT-d, scalable-mode IOMMU, PASID, SVA, IOPF, SR-IOV, PCI passthrough, GPUs, NIC accelerators, or other DMA-capable devices exposed to local users or tenants.
• Restrict untrusted local users and workloads from accessing PASID-capable devices until patched, especially on shared compute and virtualization platforms.
• Review kernel logs for historical DMAR, IOMMU, PASID, IOTLB, device-TLB, PCIe AER, device reset, or kernel oops events that correlate with local device-heavy workloads.
• Treat unexplained host crashes or IOMMU faults on affected hardware as potentially security relevant, even though there is no known public exploit or KEV listing.
• Track vendor distribution advisories for exact fixed versions, because fixed package names and backport versions vary by Linux distribution and kernel branch.