Look up another CVE · open CVE-2026-74355 in the interactive tracker
CVE-2026-74355
iommu/vt-d: Fix RB-tree corruption in probe error path
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/iommu. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74355 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The info->node RB-tree member is zero-initialized via kzalloc. If a device does not support ATS, the device_rbtree_insert() call is skipped. If a subsequent probe step fails, the error path jumps to device_rbtree_remove(), which misinterprets the zeroed node as a tree root and corrupts the device RB-tree. Fix this by explicitly initializing the RB-node as empty using RB_CLEAR_NODE() during initialization and guarding the removal with RB_EMPTY_NODE().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/iommu/intel/iommu.c
- What this is
- INTEL IOMMU (VT-d)MAINTAINERS section matched on drivers/iommu/intel/ · iommu@lists.linux.dev · Supported
Check it on the machine
grep -w CONFIG_INTEL_IOMMU /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on arm64/arm64, arm64/cloud-arm64, arm64/rt/arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidYnot built on arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_INTEL_IOMMU
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 8.2 high
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/iommu
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.40 | f5102e0fc3c6 |
| 6.15 | 7.1.5 | d16923a45d4d |
| 6.15 | 7.2 | 43bd9e6d5513 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is hit in intel_iommu_probe_device() during IOMMU device probing on the PCI bus notifier path (BUS_NOTIFY_ADD_DEVICE), which is only reachable via local kernel actions such as PCI hotplug/rescan, SR-IOV VF creation, or driver bind—not via any network protocol.
- AC:LAttack complexity, low
- A privileged attacker can reliably trigger the fault path by inducing PASID table allocation failure (e.g., memory pressure) while adding or reprobing a non-ATS PCI function on a VT-d scalable-mode host where ATS-capable devices may already populate the IOMMU device RB-tree.
- PR:HPrivileges required, high
- Reaching intel_iommu_probe_device() requires adding or reprobing PCI/IOMMU devices through kernel-local administration (CAP_SYS_ADMIN for sysfs rescan/SR-IOV, or equivalent host control); this cannot be done from an unprivileged user or user namespace alone.
- UI:NUser interaction, none
- Exploitation does not depend on any victim user action beyond the attacker (or administrator) initiating device probe/hotplug; no interactive user steps are required once the privileged trigger is performed.
- S:CScope, changed
- Corrupting the Intel VT-d device RB-tree breaks RID-to-device tracking used for IOMMU page-request and invalidation handling, which can undermine DMA/IOMMU isolation boundaries (e.g., SR-IOV/assigned-device or host DMA containment), not just the probing process itself.
- C:HConfidentiality impact, high
- Calling rb_erase() on a zero-initialized RB-node can null the tree root and corrupt kernel RB-tree pointers; such kernel memory corruption is exploitable to obtain arbitrary read primitives or leak sensitive kernel data during subsequent lookups.
- I:HIntegrity impact, high
- The erroneous rb_erase() performs out-of-tree pointer writes that corrupt IOMMU device tracking structures, providing a kernel memory corruption primitive that can be developed into arbitrary write or code execution.
- A:HAvailability impact, high
- RB-tree corruption in the IOMMU device map can cause kernel oopses/panics during later device_rbtree_find() operations in interrupt-driven VT-d page-request or invalidation-timeout paths, resulting in complete loss of kernel availability.