CVE-2026-43054
MEDIUMDescription
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 v3.1 Score
EPSS — Exploit Prediction
EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.
Weakness Type (CWE)
Affected Products
| Vendor | Product |
|---|---|
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
| linux | linux_kernel |
References
Advisories & Patches
Frequently Asked Questions
What is CVE-2026-43054? +
How severe is CVE-2026-43054? +
What products are affected by CVE-2026-43054? +
How do I check if I'm vulnerable to CVE-2026-43054? +
Related Vulnerabilities
An unauthenticated remote attacker may exhaust all available TCP connections in the CODESYS Modbus TCP Server stack if a race …
thread-amount is a tool that gets the amount of threads in the current process. Prior to version 0.2.2, there are …
Hackney fails to properly release HTTP connections to the pool after handling 307 Temporary Redirect responses. Remote attackers can exploit …
When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the …
A denial of service vulnerability exists in the HTTP Header Parsing functionality of Tenda AC6 V5.0 V02.03.01.110. A specially crafted …
IBM MQ 9.1, 9.2, 9.3, 9.4 LTS and 9.3, 9.4 CD is vulnerable to a denial of service, caused by …