CVE-2026-72086 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

scsi: xen: scsiback: Free the command tag on the TMR submit-failure path

scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag.

Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails.

transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req.

Use the same helper, which returns just the tag, on this path too.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 08/16/2026

The Linux kernel contains a resource management flaw within the Xen virtual SCSI backend driver that results in the leakage of command tags during task-management request failures. This vulnerability is located specifically in the scsiback_device_action function, which handles operations related to storage devices presented via the PVSCSI interface. The core issue arises when the system attempts to submit a task management request using target_submit_tmr after obtaining a command tag through scsiback_get_pend_req. Under normal operational conditions, this flow proceeds without incident; however, if target_submit_tmr encounters an error and returns a negative value, the execution path diverts to an error handling label designated as err. In this specific failure scenario, while the system correctly sends a response back to the guest operating system, it fails to release or free the previously allocated command tag. This omission creates a persistent resource leak that accumulates with each failed attempt at task management operations such as SCSI aborts or resets issued by the virtual machine.

The impact of this vulnerability is significant for systems relying on PVSCSI storage connectivity between Xen guests and their host infrastructure. An attacker operating within a privileged guest environment can exploit this flaw to exhaust the pool of available command tags associated with a specific Logical Unit Number session. By repeatedly issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests that trigger the failure path in target_submit_tmr, the guest can systematically deplete these resources. Once all command tags for a LUN are leaked and unavailable, subsequent legitimate I/O operations targeting that storage device will fail due to resource exhaustion. This effectively results in a denial of service condition where the affected LUN becomes unresponsive or stops functioning entirely for any other processes within the same session, disrupting critical business applications dependent on that storage volume.

The technical complexity of this vulnerability stems from the intricate reference counting and lifecycle management mechanisms inherent in the Linux SCSI target subsystem. Standard cleanup routines such as transport_generic_free_cmd cannot be safely invoked at the point where the error occurs because the command structure has already undergone partial initialization via __target_init_cmd, resulting in a non-zero kernel reference count on se_cmd->cmd_kref. Furthermore, within the internal error handling of target_submit_tmr, the function core_tmr_release_req may have already freed the se_tmr_req member while leaving flags like SCF_SCSI_TMR_CDB set and pointers dangling. Attempting to run standard command release logic at this stage would lead to a double-free vulnerability on se_tmr_req, potentially causing kernel panic or memory corruption. Therefore, the remediation requires bypassing these complex structures and utilizing a specialized helper function that isolates and returns only the specific tag identifier for immediate deallocation, ensuring clean resource cleanup without triggering secondary integrity violations.

From a classification perspective, this issue aligns with CWE-401, which describes missing release of memory after successful allocation, specifically manifesting as a resource leak in kernel space. The exploitation vector allows an unprivileged or moderately privileged user within the guest domain to impact system stability and availability, mapping closely to ATT&CK technique T1496, Resource Hijacking, where resources are consumed to degrade performance or cause denial of service. Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the error path in scsiback_device_action to properly invoke the tag release helper function. Administrators should ensure their Xen environments and guest kernels are updated with versions containing this fix. Additionally, monitoring for unusual patterns of SCSI abort or reset requests from virtual machines can serve as a detection mechanism for potential exploitation attempts before significant resource exhaustion occurs.

Responsible

Linux

Reservation

08/09/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00205

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!