Skip to main content

Linux Kernel CVE-2026-43054

| EUVD-2026-26653 MEDIUM
Missing Release of Resource after Effective Lifetime (CWE-772)
2026-05-01 Linux
5.5
CVSS 3.1
Share

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

7
Analysis Generated
May 07, 2026 - 18:37 vuln.today
CVSS changed
May 07, 2026 - 18:37 NVD
5.5 (MEDIUM)
Patch available
May 01, 2026 - 16:33 EUVD
Patch released
May 01, 2026 - 15:24 nvd
Patch available
EUVD ID Assigned
May 01, 2026 - 15:00 euvd
EUVD-2026-26653
CVE Published
May 01, 2026 - 14:15 nvd
MEDIUM 5.5
CVE Published
May 01, 2026 - 14:15 nvd
N/A

DescriptionNVD

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).

  1. 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.

AnalysisAI

tcm_loop target reset handler fails to drain in-flight SCSI commands, violating SCSI error handling contract and causing LUN reference leaks that deadlock configfs LUN unlink operations. Local users with appropriate privileges can trigger denial of service by initiating reset sequences while SCSI commands are in flight, leaving the kernel in an unkillable D-state waiting for LUN reference counts to clear. …

Sign in for full analysis, threat intelligence, and remediation guidance.

Vendor StatusVendor

Share

CVE-2026-43054 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy