CVE-2026-43054

What it actually does

This is a local denial-of-service flaw in the Linux kernel SCSI target loopback driver, tcm_loop. During SCSI error handling, tcm_loop_target_reset() can incorrectly report a successful target reset without draining in-flight SCSI commands. The kernel may then reuse scsi_cmnd structures while asynchronous target-core completion work for older commands is still pending. This race can corrupt command/LUN reference accounting, leak a LUN reference, and cause configfs LUN removal to hang indefinitely in uninterruptible sleep state. The practical technical result is a kernel-level availability failure affecting systems using the SCSI target subsystem and tcm_loop, especially during reset/error-recovery and LUN unlink operations.

Why it matters to the business

An attacker or local user with the ability to exercise affected SCSI target-loop functionality can cause storage management operations to hang and may require administrative intervention or a system reboot to recover. The most likely operational impact is loss of availability for storage target administration, blocked cleanup or reconfiguration workflows, and possible disruption to hosts relying on kernel SCSI target services. This issue is not known to be exploited in the wild, is not listed in CISA KEV, has very low EPSS, and requires local privileges, so broad internet-scale exploitation risk is low; however, the availability impact can still be significant on systems that depend on Linux kernel target storage functionality.

How an attack unfolds

Exploitation requires local access and the ability to interact with or influence the affected Linux SCSI target loopback path. An attacker triggers conditions that cause SCSI command timeout/error handling and a target reset through tcm_loop. Because the vulnerable reset handler returns success without fully draining outstanding commands and deferred completion work, the SCSI error handler may reuse command structures while target-core work still references the previous command state. This can lead to a leaked LUN reference. When an administrator or process later attempts to remove or unlink the affected LUN through configfs, the operation can block forever in transport_clear_lun_ref(), leaving processes stuck in D-state and degrading storage management availability. No public exploit maturity is indicated, and exploitation is constrained by the need for local privileges and a relevant SCSI target/tcm_loop configuration.

How to fix it

Upgrade to a Linux kernel version that includes the fix for tcm_loop_target_reset() draining outstanding commands during target reset. Because no fixed versions were provided in the input, obtain the corrected kernel from the relevant Linux distribution vendor, long-term-stable kernel branch, or upstream stable release once available. Prioritize systems that load or use target_core_mod, tcm_loop, configfs-based SCSI target configuration, LIO, loopback SCSI targets, storage test harnesses, or virtualization/storage stacks depending on the kernel target subsystem. If immediate patching is not possible, reduce exposure by disabling or unloading unused SCSI target loopback functionality, restricting local shell access, limiting permissions for storage-target administration, avoiding untrusted workloads on hosts using tcm_loop, and scheduling maintenance windows for systems where a reboot may be required if the hang occurs.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the SCSI target tcm_loop reset-drain behavior. Validate package status using the distribution package manager and compare the installed kernel build against vendor advisories or upstream stable release notes. Check whether affected modules are present or loaded with commands such as lsmod for tcm_loop, target_core_mod, and configfs-related target modules. On test systems only, validate that SCSI target reset and LUN unlink workflows complete normally and do not leave rm, rmdir, target management tools, or kernel worker threads stuck in D-state. Review dmesg or journal logs for blocked-task messages referencing transport_clear_lun_ref, core_tpg_remove_lun, target_fabric_port_unlink, configfs_unlink, or tcm_loop_target_reset. A patched system should not reproduce indefinite hangs during target reset and LUN removal under error-handling conditions.

Typical attack path

1. Obtain local access to a Linux system using the affected kernel SCSI target loopback driver.
2. Exercise tcm_loop/SCSI target functionality in a way that creates in-flight commands and triggers SCSI error handling or timeout recovery.
3. Cause or wait for tcm_loop_target_reset() to return success without draining outstanding commands.
4. Allow asynchronous target-core completion work to race with reused SCSI command structures, causing incorrect LUN reference handling.
5. Trigger LUN removal or configfs unlink of the affected target/LUN.
6. The unlink/removal operation hangs in uninterruptible sleep, causing a local denial of service for storage target management and potentially requiring reboot or service disruption to recover.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, system journals, storage-management logs, and process-state telemetry. Relevant artifacts include blocked-task warnings, processes stuck in uninterruptible sleep during configfs unlink/removal, stack traces involving transport_clear_lun_ref or target_fabric_port_unlink, and repeated SCSI error-handling or reset activity involving tcm_loop. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, audit logs for configfs target deletion operations, and EDR/process telemetry showing rm, rmdir, targetcli, or storage-management commands stuck in D-state. There are no network indicators for this issue because exploitation is local and kernel/subsystem-specific. Correlate suspicious events with local user activity, recent storage target reconfiguration, SCSI timeouts, target resets, or failed LUN deletion attempts. Threat actor exploitation has not been reported in the provided data, so detection should focus on behavioral signs of the hang rather than known malicious infrastructure or payloads.

• INFO: task rm:* blocked for more than 122 seconds
• blocked for more than 122 seconds
• transport_clear_lun_ref
• core_tpg_remove_lun
• target_fabric_port_unlink
• configfs_unlink
• vfs_unlink
• do_unlinkat
• target_core_mod
• tcm_loop_target_reset
• tcm_loop
• TMR_LUN_RESET
• CMD_T_COMPLETE
• /sys/kernel/config/target/
• process state D
• rm D

What your security team should do

• Inventory Linux systems using the kernel SCSI target subsystem, especially those with tcm_loop or target_core_mod loaded.
• Prioritize patching storage infrastructure, virtualization hosts, CI/test systems, and appliances that expose or depend on Linux kernel target/LIO functionality.
• Track Linux distribution advisories for the fixed kernel build and deploy the corrected kernel through normal kernel update processes.
• Restrict local administrative and shell access on systems using SCSI target loopback functionality until patched.
• Monitor for blocked-task kernel messages and D-state processes involving configfs LUN removal or target-core functions.
• If symptoms are observed, treat the host as availability-impaired: preserve logs, avoid repeated destructive storage reconfiguration attempts, and plan controlled recovery such as service restart or reboot if required.
• Because the vulnerability is local, low-EPSS, not KEV-listed, and has no known exploit maturity, prioritize based on use of affected SCSI target functionality rather than internet exposure alone.