In the Linux kernel, the following vulnerability has been resolved:
scsi: xen: scsiback: Free unsubmitted command instead of double-putting it
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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - 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:L - 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:N - 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:N - 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:C - 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:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:N - 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:N - 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:C - 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:H - 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:H - 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:H - 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.
CVSS 3.1