CVE-2026-43054 scsi: target: tcm_loop: Drain commands in target_reset handler
A missing command drain in the tcm_loop reset handler causes a resource leak, hanging LUN unlink operations and leading to a denial of service.
- Exploited in the wild
- Not known
- Login needed
- Any signed-in user
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-43054?
CVE-2026-43054 is a medium-severity denial of service vulnerability in Linux kernel, published on 1 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official 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.
Weakness: CWE-772
Which versions are affected by CVE-2026-43054?
It affects 1 product.
Products include Linux kernel.
How do I fix CVE-2026-43054?
Apply the vendor's patch.
Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.
Is CVE-2026-43054 being exploited?
There is no known exploitation of CVE-2026-43054 in the wild and no public exploit code.
Other vulnerabilities in Linux kernel
Sources
Also known as BELL-CVE-2026-43054, DEBIAN-CVE-2026-43054, GHSA-mf6r-pgpm-mqvq, ROOT-OS-UBUNTU-2204-CVE-2026-43054, ROOT-OS-UBUNTU-2404-CVE-2026-43054, UBUNTU-CVE-2026-43054.