In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcmloop: Drain commands in targetreset handler
tcmlooptargetreset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsieh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers "forget about timed out scmds" and is ready for new commands. Every other SCSI LLD (virtioscsi, mpt3sas, ipr, scsidebug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS.
Because tcmlooptargetreset() doesn't drain, the SCSI EH reuses in-flight scsicmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old secmd. The memset in queuecommand zeroes selun and lunrefactive, causing transportlunremovecmd() to skip its percpurefput(). The leaked LUN reference prevents transportclearlunref() from completing, hanging configfs LUN unlink forever in D-state:
INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transportclearlunref+0x78/0x90 [targetcoremod] coretpgremovelun+0x28/0xb0 [targetcoremod] targetfabricportunlink+0x50/0x60 [targetcoremod] configfsunlink+0x156/0x1f0 [configfs] vfsunlink+0x109/0x290 dounlinkat+0x1d5/0x2d0
Fix this by making tcmlooptarget_reset() actually drain commands:
Issue TMRLUNRESET via tcmloopissuetmr() to drain all commands that the target core knows about (those not yet CMDT_COMPLETE).
Use blkmqtagsetbusyiter() to iterate all started requests and flushwork() on each secmd — this drains any deferred completion work for commands that already had CMDTCOMPLETE set before the TMR (which the TMR skips via __targetcheckiostate()). This is the same pattern used by mpi3mr, scsidebug, and libsas to drain outstanding commands during reset.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43054.json"
}