Look up another CVE · open CVE-2026-72085 in the interactive tracker
CVE-2026-72085
scsi: xen: scsiback: Free unsubmitted command instead of double-putting it
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem drivers/xen. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72085 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
scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it ("refcount_t: underflow; use-after-free") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.
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/xen/xen-scsiback.c
- What this is
- XEN PVSCSI DRIVERSMAINTAINERS section matched on drivers/xen/xen-scsiback.c · xen-devel@lists.xenproject.org · Supported
- Kernel module
- xen_scsiback
Check it on the machine
grep -wE 'CONFIG_XEN|CONFIG_XEN_SCSI_BACKEND' /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.
lsmod | grep -w xen_scsibackPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
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.
- bookwormMnot built on i386/686, ppc64el/powerpc64le
- trixieMnot built on armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidMnot built on loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_XEN, CONFIG_XEN_SCSI_BACKEND
- Reads as
- all on means the file is compiled; any one off means it is not.
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
- 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/xen
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.6 | 5.15.212 | 9c0f6894982b |
| 4.6 | 6.1.178 | a13b789497a7 |
| 4.6 | 6.6.145 | fa588f284011 |
| 4.6 | 6.12.97 | fcd64d4d97af |
| 4.6 | 6.18.40 | f1516c56ac54 |
| 4.6 | 7.1.5 | 1e97c404e449 |
| 4.6 | 7.2 | ca978f8a93d4 |
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
- A malicious Xen pvSCSI guest reaches scsiback_do_cmd_fn() by posting vscsiif_request entries on the shared ring and notifying the dom0/driver-domain backend via event channel; this is a hypervisor-mediated local interface, not a routable network or physical bus path.
- AC:LAttack complexity, low
- The guest fully controls ring_req.act and grant references and can deterministically trigger the two pre-submit error paths (unknown act or failed scsiback_gnttab_data_map) on every attempt with no race, timing window, or other condition outside attacker control.
- PR:NPrivileges required, none
- Exploitation requires only a compromised or malicious Xen guest that has been granted a pvSCSI device with a mapped LUN; no dom0 account, capability, or init-namespace privilege is needed—only tenant VM control in the standard Xen multi-tenant threat model.
- UI:NUser interaction, none
- The guest frontend posts crafted pvSCSI ring requests autonomously; no victim user action on dom0 such as mounting storage, opening device nodes, or approving prompts is required beyond routine PV device assignment already present.
- S:CScope, changed
- A guest VM drives vulnerable code in the dom0/driver-domain xen-scsiback backend kernel, crossing the VM/host security boundary and impacting host kernel state, storage availability, and potentially the entire physical host.
- C:HConfidentiality impact, high
- The buggy error paths call transport_generic_free_cmd() on an uninitialized se_cmd whose cmd_kref is zero, causing refcount underflow with kernel "use-after-free" warnings; per kernel CNA guidance, refcount/UAF-class defects warrant High confidentiality impact.
- I:HIntegrity impact, high
- Refcount underflow corrupts cmd_kref without invoking the proper release path, leaving target-core command state inconsistent; per kernel CNA guidance for UAF/refcount memory-safety bugs, this warrants High integrity impact even if primary observed effect is tag leak.
- A:HAvailability impact, high
- Each trigger leaks one session command tag from the finite per-LUN pool (default 128), and exhausting all tags permanently stops the LUN; on hosts with panic_on_warn enabled the refcount underflow WARN additionally panics the host kernel.