CVE-2026-45862

What it actually does

This is a race condition in the Linux kernel Intel VT-d IOMMU PASID-table setup path. A newly allocated PASID table is expected to be zero-initialized before non-coherent IOMMU hardware can use it. The vulnerable sequence publishes the PASID-table address to the PASID directory before flushing the CPU cache for that table, creating a window where the IOMMU may read stale physical memory contents instead of the intended zeroed entries. If an attacker can influence timing and access device/IOMMU functionality, stale PASID entries could result in incorrect DMA translation state, potentially enabling memory corruption, unauthorized memory access, or denial of service. The CVSS vector indicates local access, low privileges, no user interaction, high attack complexity, and potential high confidentiality, integrity, and availability impact with scope change.

Why it matters to the business

Successful exploitation could allow a local user or workload with access to relevant device/IOMMU interfaces to compromise kernel memory isolation, potentially leading to privilege escalation, data exposure, system instability, or host crash. The risk is most relevant on Linux systems using Intel VT-d features such as PASID, Shared Virtual Addressing, accelerators, or device passthrough. Although the EPSS score is low, there is no CISA KEV listing, and no public exploit maturity is currently reported, the potential impact is severe for multi-user, virtualization, accelerator, or high-density compute environments where local isolation boundaries matter.

How an attack unfolds

An attacker first needs local execution with sufficient access to interact with hardware paths that use Intel VT-d PASID functionality, such as VFIO, assigned devices, accelerators, or Shared Virtual Addressing-capable devices. The attacker then attempts to repeatedly trigger allocation and activation of PASID tables while racing the kernel’s cache-flush ordering. In the vulnerable sequence, the PASID directory entry can become visible to the IOMMU before the zeroed PASID table contents are guaranteed to be written back to RAM. On non-coherent IOMMU hardware, the device may consume stale data left in the reused physical page. If the stale entries are meaningful and attacker timing succeeds, the IOMMU may apply unintended translations or permissions, potentially enabling DMA to memory that should not be accessible, corrupting kernel/user memory, leaking data, or crashing the system. Exploitation is expected to be hardware- and configuration-dependent and high complexity, with no known public exploit reported in the provided data.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or vendor that includes the fix for the Intel VT-d PASID-table cache-flush ordering issue. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify the first fixed kernel for each supported distribution and hardware platform. Where immediate patching is not possible, reduce exposure by disabling or restricting untrusted access to device-passthrough and accelerator interfaces, limiting membership in groups that can access VFIO or device files, avoiding assignment of PASID/SVA-capable devices to untrusted workloads, and disabling Intel IOMMU scalable-mode/PASID/SVA features where operationally acceptable. Avoid disabling the IOMMU entirely unless advised by the platform vendor, because doing so can remove important DMA isolation protections and may increase overall risk.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package version against the distribution advisory or by verifying the kernel source contains the corrected ordering in the Intel VT-d PASID setup path: the PASID table is flushed before the PASID directory entry is made visible to hardware. Reboot into the fixed kernel and verify the active kernel with uname or package inventory tooling. Validate exposure by identifying systems with Intel VT-d enabled, PASID/SVA-capable hardware, VFIO/device passthrough, or accelerator workloads. Review kernel boot parameters and dmesg output for Intel IOMMU/scalable-mode indicators. After remediation, monitor for absence of recurring IOMMU/DMAR/PASID faults and confirm untrusted users or workloads cannot access device nodes that exercise vulnerable paths unless explicitly required.

Typical attack path

1. Gain local code execution on an affected Linux system with Intel VT-d IOMMU functionality enabled.
2. Obtain access to a device interface or subsystem that can exercise PASID/SVA/VFIO/device-passthrough paths.
3. Repeatedly trigger PASID table allocation, teardown, and reuse to increase the chance of observing stale physical memory contents.
4. Race the window where the PASID directory references the new table before the table cache lines are flushed to RAM.
5. Cause non-coherent IOMMU hardware to consume stale PASID-table entries.
6. Leverage unintended DMA translations or permissions to read, modify, or corrupt memory, or to crash the host.

How to detect it

There are no reliable exploit-specific indicators for this flaw, and successful exploitation may leave no application-level logs. Detection should focus on kernel, hypervisor, and hardware telemetry. Collect and review dmesg, journald, syslog, kern.log, audit logs, EDR telemetry, and virtualization/device-assignment logs for unusual Intel IOMMU, DMAR, PASID, VFIO, or device reset activity. Look for bursts of IOMMU faults involving PASID-capable devices, repeated attach/detach or reset of assigned devices, kernel oops/panic events, unexplained memory corruption, machine-check exceptions, and local processes frequently opening VFIO or accelerator device nodes. Correlate events with local user sessions, container or VM lifecycle events, and workloads that request device passthrough. Because no public exploit maturity or named threat actor activity is reported in the provided data, absence of these artifacts does not prove non-exploitation; it only reduces suspicion.

• DMAR:
• IOMMU fault
• DMAR: DRHD: handling fault status reg
• DMAR: [DMA Read] Request device
• DMAR: [DMA Write] Request device
• fault reason
• PASID
• Intel-IOMMU
• intel_iommu
• vfio-pci
• /dev/vfio/vfio
• /dev/vfio/
• kernel BUG
• kernel panic
• Oops:
• Machine check events logged
• mce:
• device reset
• Resetting device

What your security team should do

• Prioritize patching Linux systems that use Intel VT-d with VFIO, device passthrough, accelerators, GPUs, NICs, storage adapters, or Shared Virtual Addressing/PASID-capable devices.
• Inventory affected Linux hosts and identify where Intel IOMMU, scalable mode, PASID, SVA, or device assignment is enabled.
• Apply vendor-provided fixed kernels and reboot; kernel live-patching may not fully address hardware state until systems are restarted, depending on vendor implementation.
• Until patching is complete, restrict access to /dev/vfio, accelerator device files, and administrative interfaces that permit device assignment or IOMMU configuration.
• Treat multi-tenant compute, virtualization hosts, build farms, HPC nodes, and systems running untrusted local workloads as higher priority despite the low EPSS score.
• Monitor kernel logs for DMAR/IOMMU/PASID faults, unexpected device reset events, machine checks, kernel oopses, or crashes around device assignment activity.
• Review recent local privilege escalation alerts, unexplained kernel memory corruption, and abnormal DMA/IOMMU fault patterns for possible prior exploitation.
• Track vendor advisories for exact fixed package versions, because upstream fixes may be backported under distribution-specific kernel version numbers.