Look up another CVE · open CVE-2026-72282 in the interactive tracker
CVE-2026-72282
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem arch/arm64. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72282 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 | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| 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
kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.
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.
arch/arm64/kvm/vgic/vgic-its.c
virt/kvm/kvm_main.c
- What this is
- KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)MAINTAINERS section matched on arch/arm64/kvm/ · linux-arm-kernel@lists.infradead.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
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
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/arm64
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.8 | 5.10.261 | f398b7d92cd9 |
| 4.8 | 5.15.212 | 1b4a3c2f0509 |
| 4.8 | 6.1.178 | cfe107b02a3c |
| 4.8 | 6.6.145 | 90d35d2b8e47 |
| 4.8 | 6.12.97 | e01071ea006c |
| 4.8 | 6.18.40 | 7099e7148f81 |
| 4.8 | 7.1.5 | 0cbae0e296d2 |
| 4.8 | 7.2 | 3a0724998162 |
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 reached only via host-local KVM VM file descriptor ioctls (KVM_SIGNAL_MSI, KVM_IRQFD/eventfd MSI routing) and related in-kernel MSI injection paths on arm64 GICv3 ITS; there is no network, adjacent-radio, or physical-device packet path to kvm_io_bus_get_dev() or __vgic_doorbell_to_its().
- AC:LAttack complexity, low
- Exploitation is a race where the attacker runs concurrent KVM_SIGNAL_MSI/irqfd MSI injection against vCPU teardown or VM shutdown that unregisters the matched MMIO device; the attacker controls both threads and can retry until the window is hit, so success does not depend on conditions outside attacker influence.
- PR:LPrivileges required, low
- Triggering requires local access to a KVM VM fd (typically via /dev/kvm membership or equivalent host-local VM management rights), not remote authentication; this is low-privilege local access comparable to other namespace-reachable capabilities, not init-namespace root exclusively.
- UI:NUser interaction, none
- Exploitation is fully automated through concurrent ioctl/eventfd activity and does not require any victim user action such as opening files, mounting filesystems, or interacting with the guest.
- S:UScope, unchanged
- The vulnerable code runs in the host kernel on behalf of the VM owner/VMM; impact is host kernel memory corruption and privilege escalation within the same host security authority, not a direct guest-to-host VM escape across the guest/host boundary without prior host-side KVM access.
- C:HConfidentiality impact, high
- This is a kernel use-after-free on a returned kvm_io_device/vgic_io_device pointer accessed after SRCU is dropped (ops pointer and container_of introspection), which can disclose kernel heap contents and be weaponized into arbitrary read primitives.
- I:HIntegrity impact, high
- UAF on emulated GIC MMIO device objects allows corrupting freed heap objects and hijacking function pointers/structure fields during type checking and follow-on ITS MSI handling, enabling arbitrary kernel write and local privilege escalation.
- A:HAvailability impact, high
- The UAF can cause immediate kernel oops/panic from dereferencing freed kvm_io_device memory during concurrent device unregistration, and repeated triggering can reliably deny availability even before full exploitation.