Linux KernelOperating system · Linux

CVE-2026-43161

MEDIUM · 5.5 CVSS v3.1 Published 2026-05-06
Fix available
A fix is available. Upgrade to 5.13 / 5.14 or later.
See remediation →
57/100
Remediation priority · Elevated
Zero-click Patch available

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis

A detailed technical summary for this CVE is being prepared.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 5.12.19, < 5.13>= 5.13.4, < 5.14>= 5.14.1, < 6.12.77>= 6.13, < 6.18.17>= 6.19, < 6.19.6= 5.14

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 5.13 / 5.14 / 6.12.77 or later
Fixed in 5.135.146.12.77
Vendor patch git.kernel.org →
Recommended fix High confidence

Upgrade to Linux kernel 6.18.17 or later (or 6.12.77+ for the 6.12.x branch, 5.14.0+ for 5.13.x, 5.13.0+ for 5.12.x)

  1. 1. Identify the currently running Linux kernel version using `uname -r`
  2. 2. Check which major kernel version family your current kernel belongs to (e.g., 5.12, 5.13, 5.14, 6.12, or 6.x)
  3. 3. Determine the minimum fixed version needed based on your current kernel: for 5.12.x kernels (>=5.12.19) upgrade to 5.13.0 or later; for 5.13.x kernels (>=5.13.4) upgrade to 5.14.0 or later; for 5.14.x/6.x kernels (<6.12.77) upgrade to 6.12.77 or later; for 6.13.x-6.18.x kernels (<6.18.17) upgrade to 6.18.17 or later
  4. 4. For production systems, schedule a maintenance window as kernel upgrades require system reboot
  5. 5. Obtain the fixed kernel from your distribution's package repository (e.g., `apt-get update && apt-get install linux-image-<version>` for Debian/Ubuntu, or `yum update kernel` for RHEL/CentOS)
  6. 6. After installing the new kernel, reboot the system to load the patched kernel
  7. 7. Verify the fix is applied by checking the kernel version (`uname -r`) and confirming it's >= the fixed version for your branch
Caveat Kernel upgrades may require driver compatibility checks; ensure critical hardware drivers (especially Intel IOMMU/VT-d and PCIe endpoint devices) are supported in the target kernel version

Generated from the published advisory — verify against the referenced sources before acting.

We can perform the upgrade in your staging environment and verify nothing breaks — typical engagement from $1,600. Get the upgrade done

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-43161 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-43161 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data