CVE-2026-43161

iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode

MEDIUM
5.5
CVSS Score
Published: May 6, 2026 at 11:27 AM UTC
Updated: June 17, 2026 at 10:49 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.1%

Description

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode PCIe endpoints with ATS enabled and passed through to userspace (e.g., QEMU, DPDK) can hard-lock the host when their link drops, either by surprise removal or by a link fault. Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") adds pci_dev_is_disconnected() to devtlb_invalidation_with_pasid() so ATS invalidation is skipped only when the device is being safely removed, but it applies only when Intel IOMMU scalable mode is enabled. With scalable mode disabled or unsupported, a system hard-lock occurs when a PCIe endpoint's link drops because the Intel IOMMU waits indefinitely for an ATS invalidation that cannot complete. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias device_block_translation blocking_domain_attach_dev iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(), which calls qi_flush_dev_iotlb() and can also hard-lock the system when a PCIe endpoint's link drops. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 intel_context_flush_no_pasid device_pasid_table_teardown pci_pasid_table_teardown pci_for_each_dma_alias intel_pasid_teardown_sm_context intel_iommu_release_device iommu_deinit_device __iommu_group_remove_device iommu_release_device iommu_bus_notifier blocking_notifier_call_chain bus_notify device_del pci_remove_bus_device pci_stop_and_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Sometimes the endpoint loses connection without a link-down event (e.g., due to a link fault); killing the process (virsh destroy) then hard-locks the host. Call Trace: qi_submit_sync qi_flush_dev_iotlb __context_flush_dev_iotlb.part.0 domain_context_clear_one_cb pci_for_each_dma_alias 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 __fput pci_dev_is_disconnected() only covers safe-removal paths; pci_device_is_present() tests accessibility by reading vendor/device IDs and internally calls pci_dev_is_disconnected(). On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs. Since __context_flush_dev_iotlb() is only called on {attach,release}_dev paths (not hot), add pci_device_is_present() there to skip inaccessible devices and avoid the hard-lock.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 5.12.19v ≥ 5.13.45.12.19 ≤ v < 5.135.13.4 ≤ v < 5.145.14 ≤ v < 6.12.775.14 ≤ v < 6.18.175.14 ≤ v < 6.19.65.14 ≤ v < 7.05.14.1 ≤ v < 6.12.776.13 ≤ v < 6.18.176.19 ≤ v < 6.19.637764b952e1b39053defc7ebe5dcd8c4e3e78de95.12.195.13.45.145.14 rc25.14 rc35.14 rc45.14 rc55.14 rc65.14 rc7948ec6d003280d49aca49b366aa5cb140f87434d99301a53a1378f8863ac7850b9589f997bb0e125
Vendor states this is fixed in 42662d19839f34735b718129ea200e3734b07e50 (fixed)
Vendor states this is fixed in 48b3f08e68b29a79527869cdde7298ca2a9b9646 (fixed)
Vendor states this is fixed in bc0490ad9edf5c6f98e39fbbee2877b85261a5ae (fixed)
Vendor states this is fixed in e70d5feb10c5ba2bbf7ca400b8f39a2f82d653e8 (fixed)
Affected range stops below 5.13, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.14 (unaffected)
Vendor states this is fixed in 6.12.77 (unaffected)
Vendor states this is fixed in 6.18.17 (unaffected)
Vendor states this is fixed in 6.19.6 (unaffected)
Vendor states this is fixed in 7.0 (unaffected)

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card