CVE-2026-52953

What it actually does

This Linux kernel flaw is an out-of-scope memory access in the Intel VT-d IOMMU path when removing a device PASID from a dummy/global blocked IOMMU domain that does not have the expected dmar_domain backing structure. Under affected VFIO/IOMMU device-assignment workflows, such as closing or killing a QEMU process using assigned PCI devices, the kernel can dereference invalid domain state and trigger a general protection fault/oops. The practical technical impact is local kernel crash or instability, primarily a denial-of-service condition on systems using Intel IOMMU, VFIO, PCI passthrough, nested translation, or related virtualization features.

Why it matters to the business

Systems that rely on Linux virtualization with PCI passthrough or VFIO can become unstable or crash when affected device teardown paths are exercised. For organizations running virtualized workloads, this can interrupt guest VMs, disrupt hosts, require emergency reboots, and reduce confidence in maintenance operations such as stopping or restarting QEMU/KVM workloads. Current exploitation likelihood appears low based on the provided EPSS score and no KEV listing, but the operational impact can be significant for dense virtualization hosts or environments where untrusted users can start, stop, or control passthrough-enabled VMs.

How an attack unfolds

An attacker would need local access to a system where the vulnerable kernel code path is reachable, typically through permission to operate a VM, QEMU process, VFIO device, or PCI passthrough workflow. The attacker triggers teardown of a VFIO-assigned device, for example by terminating a QEMU process or causing the VFIO file descriptor/device binding to close. During device reset and IOMMU cleanup, the kernel calls into the Intel VT-d PASID removal path. If the device is associated with the global blocked dummy domain rather than a full dmar_domain, the vulnerable code accesses memory beyond the expected IOMMU domain structure, causing a kernel oops/general protection fault. The end result is denial of service through host kernel crash or degraded host stability rather than direct remote code execution.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the upstream fix for the Intel VT-d IOMMU domain_remove_dev_pasid() handling. Because no exact fixed package versions were provided, track vendor advisories for the deployed kernel stream and update to the first kernel release that contains the fix. Where immediate patching is not possible, reduce exposure by limiting who can create or terminate VFIO/QEMU passthrough workloads, avoiding passthrough of PCI devices to untrusted tenants or users, disabling nested IOMMU/PASID-related configurations where feasible, and scheduling controlled restarts of affected virtualization hosts after kernel updates. Mitigations should be treated as risk reduction only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed release for the deployed distribution or contains the upstream patch that returns early in domain_remove_dev_pasid() for the blocked/dummy domain case. Validate exposure by inventorying hosts with Intel VT-d/IOMMU enabled and VFIO, IOMMUFD, PCI passthrough, or QEMU/KVM assigned-device usage. After patching, perform a controlled regression test by starting and stopping a VM that uses VFIO PCI passthrough and verifying that the host does not log a kernel oops, general protection fault, or stack trace involving domain_remove_dev_pasid(), intel_nested_set_dev_pasid(), vfio_pci_core_close_device(), or pcie_flr(). Review dmesg, journald, kern.log, syslog, and crash dump tooling for absence of the vulnerable call trace after the update.

Typical attack path

1. Obtain local access or delegated control over a Linux host workflow that can use QEMU/KVM, VFIO, IOMMUFD, PCI passthrough, or assigned devices.
2. Start or interact with a VM/process using VFIO-managed PCI device assignment on hardware using Intel VT-d/IOMMU features.
3. Trigger device close, unbind, reset, or teardown, commonly by killing or stopping the QEMU process.
4. Cause the kernel to enter the VFIO PCI close path and invoke PCI function reset and IOMMU PASID cleanup.
5. Reach domain_remove_dev_pasid() with a dummy/global blocked IOMMU domain lacking the expected Intel dmar_domain structure.
6. Trigger a kernel oops/general protection fault, causing host instability or denial of service.

How to detect it

Look for evidence of prior kernel crashes or oops events around VM shutdown, QEMU termination, VFIO device close, PCI function reset, or IOMMU/PASID cleanup. Relevant sources include dmesg, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore records, hypervisor management logs, QEMU service logs, and EDR telemetry showing QEMU process termination shortly before a host crash. Search for the specific call trace functions shown in the advisory, especially domain_remove_dev_pasid(), intel_nested_set_dev_pasid(), __iommu_set_group_pasid(), pci_dev_reset_iommu_done(), pcie_flr(), vfio_pci_core_close_device(), vfio_df_close(), and vfio_device_fops_release(). Also correlate timestamps of kernel general protection faults with VM stop/delete/reset actions or kill signals sent to QEMU processes. There are no known public actor-specific indicators in the provided data; detection should focus on crash artifacts and abuse of local VFIO/QEMU teardown paths.

• Oops: general protection fault, probably for non-canonical address
• domain_remove_dev_pasid
• intel_nested_set_dev_pasid
• __iommu_set_group_pasid
• pci_dev_reset_iommu_done
• pcie_flr
• __pci_reset_function_locked
• vfio_pci_core_close_device
• vfio_df_close
• vfio_df_unbind_iommufd
• vfio_device_fops_release
• do_raw_spin_lock
• _raw_spin_lock_irqsave
• [vfio_pci_core]
• kill QEMU process
• qemu-system
• /var/crash
• /var/lib/systemd/coredump
• vmcore
• kdump

What your security team should do

• Prioritize patching Linux virtualization hosts that use Intel VT-d/IOMMU, VFIO, PCI passthrough, IOMMUFD, or QEMU/KVM assigned devices.
• Inventory systems where untrusted or semi-trusted users can start, stop, or kill passthrough-enabled VM processes, because they are more likely to expose the vulnerable path.
• Until patched, restrict administrative and automation access that can terminate QEMU/VFIO workloads or perform PCI device reset/unbind operations.
• Monitor kernel logs and crash reports for general protection faults or oops traces containing domain_remove_dev_pasid, intel_nested_set_dev_pasid, vfio_pci_core_close_device, or pcie_flr.
• Coordinate kernel updates with virtualization maintenance windows because remediation requires booting into a fixed kernel.
• Treat this as a local denial-of-service risk rather than an internet-exposed remote compromise based on currently provided exploit maturity, EPSS, and KEV status.