CVE-2026-43161

What it actually does

This is a Linux kernel denial-of-service flaw in the Intel VT-d IOMMU driver affecting systems that use PCIe endpoints with Address Translation Service (ATS), especially devices passed through to userspace workloads such as QEMU/KVM guests, VFIO, or DPDK applications. When an ATS-enabled PCIe endpoint becomes inaccessible because of surprise removal, hot-plug removal, link loss, or certain PCIe link faults, the kernel may still issue a device IOTLB invalidation request. With Intel IOMMU scalable mode disabled or unsupported, the invalidation may never complete, causing the kernel to wait indefinitely in the IOMMU flush path and hard-lock the host. The result is a local availability impact: the host can become unresponsive and require a power cycle or out-of-band reset.

Why it matters to the business

A vulnerable host can freeze completely when a passed-through PCIe device disappears or develops a link fault, disrupting virtual machines, packet-processing applications, storage/network functions, and other workloads that depend on PCI passthrough. In environments using GPU, NIC, accelerator, or other PCIe passthrough at scale, this can create operational outages, forced reboots, service-level violations, and potential data loss from abruptly stopped workloads. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no public exploit maturity reported, but it is operationally important for infrastructure that relies on VFIO, QEMU/KVM passthrough, DPDK, PCIe hot-plug, or Intel VT-d configurations without scalable mode.

How an attack unfolds

An attacker needs local capability to interact with or influence an ATS-enabled PCIe endpoint that is attached to the host IOMMU, commonly through a workload that uses PCI passthrough such as a VM, VFIO consumer, or DPDK process. The attacker or fault condition causes the PCIe endpoint to become inaccessible, for example through surprise removal, triggering a link fault, hot-plug slot removal, device reset behavior that drops the link, or termination of a userspace passthrough process after the endpoint has stopped responding. During device detach or release, the Intel VT-d driver attempts to flush the device IOTLB. Because the endpoint is no longer reachable, the invalidation does not complete and the kernel waits indefinitely in the queued invalidation path. The host then hard-locks, causing all workloads on that host to lose availability until the machine is forcibly reset.

How to fix it

Upgrade to a Linux kernel build that includes the upstream Intel VT-d fix to skip device IOTLB flushes for inaccessible PCIe devices when scalable mode is not enabled. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, hypervisor platform, or cloud image provider. Prioritize systems using Intel VT-d with PCI passthrough, VFIO, QEMU/KVM device assignment, DPDK, SR-IOV, PCIe hot-plug, or ATS-capable NICs/accelerators. If immediate patching is not possible, reduce exposure by avoiding passthrough of unstable or hot-pluggable ATS-capable devices, disabling device assignment for hardware showing PCIe link errors, moving critical workloads away from affected hosts, scheduling maintenance for suspect hardware, and ensuring out-of-band management is available for recovery. Where operationally acceptable and vendor-supported, review IOMMU/ATS/scalable-mode-related kernel and firmware settings as compensating controls, but do not rely on configuration changes as a substitute for applying the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or vendor advisory level includes the Intel VT-d patch for skipping dev-IOTLB flushes when PCI devices are inaccessible. Validate that hosts have rebooted into the patched kernel, not merely installed it. Inventory systems for Intel IOMMU use by checking boot configuration and kernel messages for VT-d/IOMMU enablement, and identify passthrough consumers such as VFIO, QEMU/KVM, libvirt, and DPDK. For exposure validation, look for ATS-capable PCIe devices assigned to userspace and hosts with IOMMU scalable mode disabled or unsupported. In controlled maintenance only, exercise device detach/release paths for representative passthrough devices and confirm the host remains responsive; do not reproduce surprise-removal or link-fault scenarios on production hosts. Review kernel, journald, pstore, kdump, BMC, and hypervisor logs for prior hangs around PCIe link events, VFIO release, VM destruction, or IOMMU device IOTLB flush call traces.

Typical attack path

1. Identify a Linux host using Intel VT-d/IOMMU with ATS-capable PCIe devices, especially devices assigned to QEMU/KVM, VFIO, or DPDK userspace workloads.
2. Obtain local privileges or workload control sufficient to manage, reset, detach, or otherwise influence the passed-through PCIe device or its userspace consumer.
3. Cause the PCIe endpoint to become inaccessible through surprise removal, hot-plug/link disruption, device fault, or a passthrough workload lifecycle action after the link has failed.
4. Trigger a kernel attach, detach, release, or teardown path for the affected device, such as VM destruction, process termination, VFIO group release, PCI device removal, or IOMMU domain detach.
5. The Intel VT-d driver issues a device IOTLB/ATS invalidation to an inaccessible endpoint and waits indefinitely.
6. The host hard-locks, causing a denial of service until manual or out-of-band recovery is performed.

How to detect it

Detection is difficult because successful exploitation or triggering can hard-lock the host before complete logs are written. Review persistent logs from journald, syslog, kernel ring buffer captures, pstore/ramoops, kdump/vmcore data, BMC/iDRAC/iLO event logs, hypervisor management logs, and libvirt/QEMU/VFIO/DPDK application logs. Focus on events immediately before an unplanned host reset or loss of telemetry: PCIe hot-plug or link-down messages, AER link errors, device surprise removal, VFIO group release, VM destroy/shutdown actions, DPDK process termination, and Intel IOMMU/DMAR queued invalidation activity. Kernel call traces containing qi_submit_sync, qi_flush_dev_iotlb, __context_flush_dev_iotlb, intel_iommu_release_device, pciehp_handle_presence_or_link_change, or vfio_iommu_type1_detach_group are strong forensic indicators. Also correlate management-plane actions such as VM destruction or device detach with a sudden host heartbeat loss. Absence of evidence is not proof of non-exploitation because a hard lock may prevent log flushing.

• qi_submit_sync
• qi_flush_dev_iotlb
• __context_flush_dev_iotlb
• domain_context_clear_one_cb
• device_block_translation
• blocking_domain_attach_dev
• iommu_deinit_device
• __iommu_group_remove_device
• iommu_release_device
• intel_iommu_release_device
• intel_pasid_teardown_sm_context
• device_pasid_table_teardown
• pci_pasid_table_teardown
• intel_context_flush_no_pasid
• vfio_iommu_type1_detach_group
• vfio_group_detach_container
• vfio_group_fops_release
• pciehp_handle_presence_or_link_change
• pciehp_unconfigure_device
• pciehp_disable_slot
• pci_stop_and_remove_bus_device
• pci_remove_bus_device
• virsh destroy
• DMAR
• IOMMU
• ATS Invalidation
• dev-iotlb
• device IOTLB
• PCIe Bus Error
• AER:
• link down
• Data Link Layer Link Active not set
• vfio-pci

What your security team should do

• Prioritize patching hosts that use Intel VT-d with PCI passthrough, VFIO, QEMU/KVM, DPDK, SR-IOV, or ATS-capable PCIe devices.
• Create an inventory of systems with IOMMU enabled and userspace-owned PCIe devices, including hypervisors, NFV platforms, storage appliances, and accelerator/GPU hosts.
• Treat unexplained host hard-locks during VM shutdown, VFIO process exit, PCIe hot-plug, or device removal as potentially related until ruled out.
• Temporarily evacuate critical workloads from hosts with known PCIe link instability or recurring AER/hot-plug errors until patched and hardware health is confirmed.
• Ensure remote console, BMC, watchdog, and automated recovery procedures are available because exploitation may leave no complete OS-level logs.
• Add SIEM searches for IOMMU, VFIO, PCIe hot-plug, and call-trace indicators associated with the vulnerable paths.
• After patching, verify that all affected hosts are actually running the fixed kernel after reboot and that old vulnerable kernels are not selected by default boot entries.