CVE-2026-43130

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel Intel VT-d IOMMU path. In scalable mode, the kernel may issue a device IOTLB / ATS invalidation to a PCIe device that is not actually accessible because the PCIe link is down or faulted. The previous safety check only avoided invalidation for devices marked as disconnected, but did not reliably cover fault-induced link-down states. When VFIO, PASID teardown, device attach/detach, dirty tracking setup, or IOMMU domain changes trigger this path, the invalidation can cause a kernel hard lockup, making the host unresponsive and requiring reboot or power cycling. Confidentiality and integrity are not directly affected; the primary impact is host availability.

Why it matters to the business

Systems using Linux with Intel VT-d/IOMMU, PCIe passthrough, VFIO, SR-IOV, GPU/NIC acceleration, or virtualization workloads may experience sudden host freezes during device fault handling or VM teardown. This can interrupt hosted workloads, cause service downtime, require manual recovery, and potentially affect multiple virtual machines or tenants sharing the same physical host. The risk is lower than remotely exploitable vulnerabilities because exploitation requires local access or operational control over affected device/VM workflows, and there is currently no known public exploitation, KEV listing, or ransomware association. However, organizations running high-availability virtualization or accelerator-heavy infrastructure should prioritize kernel updates because a single host lockup can have broad operational impact.

How an attack unfolds

An attacker or malfunctioning local workload needs the ability to interact with a PCIe device through virtualization, VFIO, or related IOMMU-backed device assignment workflows. The attacker causes or waits for a PCIe device accessibility fault, such as a link-down or failed passthrough condition, then triggers a cleanup or detach path such as destroying a VM, releasing a VFIO group, detaching an IOMMU group, tearing down a PASID entry, or changing the device domain. The vulnerable kernel incorrectly decides that the device is safe to invalidate because it is not formally marked as disconnected. It then submits an ATS/device-IOTLB invalidation to a device that cannot respond correctly. This can wedge the VT-d invalidation path and result in a kernel hard lockup, taking the host offline until it is rebooted. Threat intelligence signals are currently low: EPSS is approximately 0.00123 with no 30-day upward trend, no known exploit maturity, and no CISA KEV listing.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the Intel VT-d IOMMU change to flush the device IOTLB only when the PCIe device is present and accessible in scalable mode. No exact fixed package versions were provided in the source data, so use the fixed kernel packages from the relevant Linux distribution, hardware vendor, cloud image provider, or kernel stable branch once published. Prioritize virtualization hosts, systems using VFIO or PCI passthrough, and servers with high-value PCIe accelerators such as GPUs, high-speed NICs, or storage adapters. If immediate patching is not possible, reduce exposure by limiting local users or automation that can manage passthrough devices, avoiding unnecessary VFIO assignment, disabling or restricting PCIe passthrough/SR-IOV where feasible, isolating workloads that can manipulate device assignment, and scheduling maintenance windows for hosts that have recently shown PCIe link instability or IOMMU faults.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix for the Intel VT-d IOMMU ATS/device-IOTLB invalidation presence check. Validate through the distribution package changelog, kernel advisory, or source commit history rather than relying only on the kernel version string, because fixes may be backported. On representative non-production systems, exercise VFIO or PCI passthrough attach/detach, VM shutdown/destroy, PASID teardown, and device reassignment workflows while monitoring for kernel hard lockups, NMI watchdog reports, and VT-d/IOMMU call traces. Confirm that hosts no longer freeze when a passthrough device is unavailable or faulted. Also verify that operational monitoring can alert on kernel hard lockups and repeated IOMMU/VFIO errors.

Typical attack path

1. Obtain local access or delegated operational control over a workload that can use VFIO, PCIe passthrough, SR-IOV, PASID, or IOMMU-backed device assignment.
2. Place or encounter a PCIe device in an inaccessible fault state, such as link-down or failed passthrough attachment, without it being treated as safely disconnected by the kernel.
3. Trigger a device cleanup or transition path, such as VM destruction, VFIO container release, IOMMU group detach, device attach/release, PASID removal, or dirty-tracking setup.
4. Cause the kernel Intel VT-d path to issue an ATS/device-IOTLB invalidation to the inaccessible PCIe device.
5. The invalidation path hangs, leading to a kernel hard lockup and loss of host availability.

How to detect it

Look for evidence of kernel hard lockups or hangs around VM teardown, VFIO release, PCIe passthrough failures, or IOMMU device detach operations. Useful log sources include kernel ring buffer output, persistent system journal entries, syslog/kern.log/messages, hypervisor management logs, libvirt logs, crash dump records, watchdog/NMI reports, and out-of-band management event logs showing resets or power cycles. Search for call traces containing Intel VT-d IOMMU invalidation functions such as qi_submit_sync, qi_flush_dev_iotlb, intel_pasid_tear_down_entry, device_block_translation, iommu_detach_group, and vfio_iommu_type1_detach_group. Correlate these with administrative events such as VM destroy/shutdown, passthrough device detach, PCIe link-down errors, AER errors, or VFIO group/container release. Because a hard lockup may prevent complete logging, absence of a full trace does not rule out exploitation or triggering; unexpected host freezes following PCIe or VFIO errors should be investigated. There are no known attacker-specific network indicators, malware artifacts, or named threat actor patterns associated with this vulnerability based on the provided intelligence.

• qi_submit_sync
• qi_flush_dev_iotlb
• intel_pasid_tear_down_entry
• device_block_translation
• blocking_domain_attach_dev
• __iommu_attach_device
• __iommu_device_set_domain
• __iommu_group_set_domain_internal
• iommu_detach_group
• vfio_iommu_type1_detach_group
• vfio_group_detach_container
• vfio_group_fops_release
• devtlb_invalidation_with_pasid
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: watchdog: BUG: soft lockup
• DMAR:
• IOMMU
• VFIO
• PCIe Bus Error
• AER: Corrected error
• AER: Uncorrected
• virsh destroy

What your security team should do

• Inventory Linux hosts that use Intel VT-d/IOMMU, VFIO, PCIe passthrough, SR-IOV, GPU passthrough, high-speed NIC passthrough, or accelerator assignment to virtual machines.
• Prioritize patching virtualization and accelerator hosts even though the vulnerability is local and not currently known to be exploited in the wild.
• Track Linux distribution and vendor advisories for the exact fixed kernel builds, and deploy the patched kernel during the next controlled maintenance window for exposed systems.
• Restrict access to VM lifecycle operations and passthrough device management to trusted administrators and automation until patched.
• Review recent kernel logs and outage records for unexplained hard lockups involving IOMMU, VT-d, VFIO, PASID, ATS, or PCIe device faults.
• Where patching is delayed, reduce use of passthrough for unstable PCIe devices and consider disabling affected device-assignment workflows on high-criticality hosts.
• Ensure host watchdog, out-of-band management, and automated evacuation/recovery procedures are functioning, because successful exploitation may leave the OS unable to log or shut down cleanly.