Look up another CVE · open CVE-2026-52953 in the interactive tracker
CVE-2026-52953
iommu/vt-d: Fix oops due to out of scope access
Published 2026-06-24 (4 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-52953 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 | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain.
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-06-24 (4 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.5% 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.6 | 6.18.33 | 88397fad7914 |
| 6.6 | 7.0.10 | 1e659db46847 |
| 6.6 | 7.1 | a6dea58d8625 |
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 vulnerable path is reached from local VFIO/iommufd device operations, such as a QEMU process closing or resetting an assigned PCI device with PASID state. It is not reachable by unauthenticated network traffic.
- AC:LAttack complexity, low
- Once an Intel VT-d system with a PASID/ATS-capable VFIO PCI device is available, the trigger is deterministic: attach a PASID domain and close or reset the device. No race or condition outside attacker control is required.
- PR:LPrivileges required, low
- The attacker needs local permission to open and operate the VFIO device and iommufd, but the relevant ioctls do not require real root after device access is granted. This is low privilege rather than unauthenticated access.
- UI:NUser interaction, none
- The attacker can trigger the bug by their own process closing/exiting or issuing device reset operations. No separate victim action is required.
- S:UScope, unchanged
- The impact is within the host kernel/IOMMU management context and does not demonstrate an IOMMU bypass or VM escape. Standard local kernel impact remains unchanged scope.
- C:NConfidentiality impact, none
- The bug is an invalid out-of-object access that oopses in the spinlock path, with no data returned to the attacker. There is no demonstrated information disclosure primitive.
- I:HIntegrity impact, high
- The bad cast treats the static blocked domain as a larger Intel dmar_domain and performs spinlock/list-related accesses beyond the real object. This is kernel memory corruption, so under the higher-severity rule integrity impact is High.
- A:HAvailability impact, high
- The commit documents a general protection fault/oops during QEMU teardown. A local attacker with VFIO device access can crash the kernel, causing high availability impact.