Bug 2516331 (CVE-2026-72086)

Summary: CVE-2026-72086 kernel: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's `scsi: xen: scsiback` component. A pvSCSI guest can trigger a resource leak by issuing specific SCSI (Small Computer System Interface) requests when a task management operation fails. This vulnerability allows the guest to leak command tags associated with a Logical Unit Number (LUN) session, which can lead to a Denial of Service (DoS) by stopping the LUN.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-15 06:06:56 UTC 
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.
Comment 1 Keith Grant 2026-08-17 20:42:17 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026081522-CVE-2026-72086-b22d@gregkh/T