CVE-2026-43130
Awaiting Analysis Awaiting Analysis - Queue
IOMMU dev-IOTLB Flush Flaw in Linux Kernel

Publication date: 2026-05-06

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: 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 __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-06
Last Modified
2026-05-08
Generated
2026-06-16
AI Q&A
2026-05-06
EPSS Evaluated
2026-06-15
NVD
CVE-2026-43130
EUVD
EUVD-2026-27689
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.7.11 (inc) to 6.8 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.16 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.6 (exc)
linux linux_kernel From 5.10.214 (inc) to 5.10.252 (exc)
linux linux_kernel From 5.15.153 (inc) to 5.15.202 (exc)
linux linux_kernel From 6.1.83 (inc) to 6.1.165 (exc)
linux linux_kernel From 6.6.23 (inc) to 6.6.128 (exc)
linux linux_kernel From 6.8.2 (inc) to 6.12.75 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Mitigation Strategies

The vulnerability has been resolved in the Linux kernel by changing the logic to flush dev-IOTLB only when the PCIe device is accessible in scalable mode, using pci_device_is_present() instead of pci_dev_is_disconnected() to avoid hard-lockups caused by link-down faults.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes the fix described in commit 4fc82cd907ac or later.

Executive Summary

This vulnerability exists in the Linux kernel's iommu/vt-d subsystem. It involves improper handling of PCIe device accessibility in scalable mode. Specifically, the system relies on a function pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but this does not cover cases where the PCIe link is down due to faults. As a result, if a virtual machine fails to connect to a PCIe device and resources are released (for example, via "virsh destroy"), the system can experience a hard lockup during the release process.

The issue arises because the system does not properly flush the device IOTLB (Input-Output Translation Lookaside Buffer) when the PCIe device is inaccessible due to faults, leading to a hard lock. The fix involves using a more reliable check pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, improving system stability.

Impact Analysis

This vulnerability can cause a hard lockup of the system when a PCIe device becomes inaccessible due to faults, especially in virtualized environments where virtual machines connect to PCIe devices. For example, if a VM fails to connect and resources are released, the system may freeze during this process.

Such a hard lockup can lead to system downtime, loss of availability, and potential disruption of services relying on the affected hardware or virtual machines.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43130. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart