CVE-2026-72085 in Linux
Summary
by MITRE • 08/15/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/16/2026
The vulnerability in question resides within the Linux kernel's SCSI backend implementation for Xen virtualization environments, specifically affecting the scsiback component. This issue stems from a fundamental misunderstanding of reference counting mechanics during command lifecycle management. When the function scsiback_get_pend_req is invoked to obtain a command tag, it initializes a vscsibk_pend structure where the embedded se_cmd object has its memory zeroed out via memset. Consequently, the cmd_kref field within this structure starts at zero. The proper initialization of this reference count occurs later in the process flow, specifically during scsiback_cmd_exec when the command is successfully submitted along the VSCSIIF_ACT_SCSI_CDB path using target_init_cmd which calls kref_init. However, error handling paths that trigger before submission fail to account for this uninitialized state.
Two specific error conditions lead to problematic behavior: a failure in scsiback_gnttab_data_map and an encounter with an unknown ring_req.act value. In both scenarios, the code path invokes transport_generic_free_cmd on the pending request's se_cmd structure. This function internally calls kref_put to decrement the reference count. Because the refcount was never incremented from its initial zero state due to the early exit before target_init_cmd execution, this operation results in a severe underflow of the refcount_t type. The kernel detects this anomaly as a use-after-free condition because the release function associated with the command is not executed properly when the count goes negative or wraps around unexpectedly.
The operational impact of this vulnerability is significant for systems running paravirtualized SCSI guests connected to Xen hosts. An attacker controlling such a guest can exploit these error paths by submitting requests containing invalid grant references or unrecognized request types. Each successful exploitation allows the guest to leak command tags associated with a Logical Unit Number session. Over time, as more tags are leaked and not properly returned to the pool of available identifiers, the LUN becomes unable to process new I/O operations effectively, leading to a denial of service condition where the storage device appears unresponsive or stopped entirely.
Under kernel configurations that enable panic_on_warn, this vulnerability escalates from a resource leak into a system-wide crash. The refcount underflow triggers a warning which immediately causes the host machine to panic and reboot. This transforms what might otherwise be a localized denial of service affecting specific storage sessions into a complete availability compromise for the entire virtualization host infrastructure. Such instability undermines the reliability guarantees expected in enterprise cloud or data center environments relying on Xen-based virtualization.
The resolution involves restructuring how early-stage command errors are handled to respect reference counting semantics. A new helper function was introduced that correctly manages the lifecycle of pending commands by calling target_free_tag directly rather than attempting to free a fully initialized se_cmd structure prematurely. This approach ensures that the tag is released while the v2p reference still securely pins the session, preventing premature deallocation issues. Additionally, the fix includes snapshotting response fields before freeing the tag because releasing it may allow another ring request to reuse the pending_req slot immediately, which could lead to data corruption if responses are written to stale memory locations after reallocation.
From a classification perspective, this vulnerability aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding reference count underflows leading to use-after-free conditions. It also relates to CWE-401 Missing Release of Memory after Effective Lifetime as the leaked command tags represent persistent resource exhaustion if not properly cleaned up in error paths. In terms of attack vectors and techniques, this maps to ATT&CK technique T1496 Resource Hijacking where an adversary consumes system resources like memory or identifiers to degrade performance or cause denial of service. The exploitation requires local access within a paravirtualized guest environment with privileges to submit SCSI commands to the backend driver.
Mitigation strategies primarily involve applying the kernel patch that corrects the reference counting logic in scsiback_do_cmd_fn and related functions. Administrators should ensure their Xen hosts are updated with versions of the Linux kernel containing this fix. For environments where immediate patching is not feasible, restricting access to paravirtualized SCSI devices or implementing strict input validation on guest-side request submission can reduce exposure. Monitoring for unusual patterns in storage I/O errors and monitoring refcount warnings in system logs such as dmesg can help detect potential exploitation attempts before they lead to complete session exhaustion or host panics.