CVE-2026-43054
Analyzed Analyzed - Analysis Complete
SCSI Target Loop Driver Command Drain Failure in Linux Kernel

Publication date: 2026-05-01

Last updated on: 2026-05-07

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Drain commands in target_reset handler tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsi_eh.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 (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS. Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight scsi_cmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old se_cmd. The memset in queuecommand zeroes se_lun and lun_ref_active, causing transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN reference prevents transport_clear_lun_ref() 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 transport_clear_lun_ref+0x78/0x90 [target_core_mod] core_tpg_remove_lun+0x28/0xb0 [target_core_mod] target_fabric_port_unlink+0x50/0x60 [target_core_mod] configfs_unlink+0x156/0x1f0 [configfs] vfs_unlink+0x109/0x290 do_unlinkat+0x1d5/0x2d0 Fix this by making tcm_loop_target_reset() actually drain commands: 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that the target core knows about (those not yet CMD_T_COMPLETE). 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and flush_work() on each se_cmd — this drains any deferred completion work for commands that already had CMD_T_COMPLETE set before the TMR (which the TMR skips via __target_check_io_state()). This is the same pattern used by mpi3mr, scsi_debug, and libsas to drain outstanding commands during reset.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-01
Last Modified
2026-05-07
Generated
2026-06-16
AI Q&A
2026-05-01
EPSS Evaluated
2026-06-15
NVD
CVE-2026-43054
EUVD
EUVD-2026-26653
Affected Vendors & Products
Showing 11 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.22 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.168 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.12 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.81 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.134 (exc)
linux linux_kernel From 5.13 (inc) to 5.15.203 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-772 The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's SCSI target driver tcm_loop. The function tcm_loop_target_reset() violates the SCSI error handling contract by returning SUCCESS without properly draining any in-flight SCSI commands. According to the SCSI error handling documentation, when a reset handler returns SUCCESS, it must ensure that all timed-out commands are forgotten and the driver is ready for new commands.

Because tcm_loop_target_reset() does not drain these commands, the system reuses command structures for recovery commands while the target core still has asynchronous completion work queued for the old commands. This causes certain references to leak, preventing the completion of LUN (Logical Unit Number) unlink operations and causing processes to hang indefinitely in an uninterruptible sleep state.

The fix involves making tcm_loop_target_reset() properly drain commands by issuing a LUN reset to clear all known commands and iterating over started requests to flush any deferred completion work, ensuring no commands remain pending before returning SUCCESS.

Impact Analysis

This vulnerability can cause processes that attempt to unlink SCSI LUNs to hang indefinitely in an uninterruptible sleep state (D-state). This happens because leaked references prevent the completion of LUN unlink operations, leading to resource leaks and potential system instability.

In practical terms, this means that storage devices managed by the affected driver may not be properly removed or reset, potentially causing system hangs or degraded performance when managing SCSI targets.

Detection Guidance

This vulnerability causes the configfs LUN unlink operation to hang indefinitely in a D-state, which can be detected by observing blocked tasks related to LUN removal.

You can look for system logs or kernel messages indicating tasks blocked for extended periods, such as messages showing a process stuck in D-state with call traces involving transport_clear_lun_ref, core_tpg_remove_lun, or configfs_unlink.

Specific commands to detect this condition include:

  • Check for blocked tasks in D-state using: ps aux | grep ' D '
  • Examine kernel logs for hung tasks or call traces: dmesg | grep -i 'blocked' or dmesg | grep -i 'transport_clear_lun_ref'
  • Use system monitoring tools like top or htop to identify processes stuck in uninterruptible sleep (D-state).
Mitigation Strategies

The vulnerability is fixed by ensuring that the tcm_loop_target_reset() function properly drains all in-flight SCSI commands before returning success.

Immediate mitigation steps include:

  • Update the Linux kernel to a version that includes the fix for this vulnerability.
  • If updating is not immediately possible, avoid using the tcm_loop target driver or disable it if feasible.
  • Monitor for symptoms such as hung configfs LUN unlink operations and blocked tasks in D-state, and restart affected services or the system if necessary.
Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43054. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart