CVE-2026-43054

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.

Gravité et risque d'exploitation

CVE-2026-43054 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.16 %, ce qui la place devant 5.1 % des CVE référencées.

Que faire ?

• Vérifiez si Linux (versions <=6.1.*, <103f79e4949513247d763c6e7f3cbbf62017afdf, <=6.12.*, <757c43c692294cdfad31390accc0e90429b2ef8a, <5.13, <7cbd69aaa507b1245240a28022bf5da0f07c68d9, 0, 6.6.134, 7.0, <05ac3754467363558a0a54ae4bb7c89b2c9574cf, <1333eee56cdf3f0cf67c6ab4114c2c9e0a952026, <=6.6.*, <=6.19.*, 5.15.203, 5.13, <=6.18.*, 6.12.81, e0eb5d38b732b011cd9ed5b1bf9f59b83c2500d3, <=*, <=5.15.*, <a836054ea81014117ec6b73529a21626a9e1f829, 6.1.168, 6.18.22, 6.19.12, <15f5241d5a52364a7e7867b49128b0442dbcad9d) est présent sur votre parc.
• Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
• À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
• Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références

• https://git.kernel.org/stable/c/757c43c692294cdfad31390accc0e90429b2ef8a
• https://git.kernel.org/stable/c/103f79e4949513247d763c6e7f3cbbf62017afdf
• https://git.kernel.org/stable/c/15f5241d5a52364a7e7867b49128b0442dbcad9d
• https://git.kernel.org/stable/c/7cbd69aaa507b1245240a28022bf5da0f07c68d9
• https://git.kernel.org/stable/c/a836054ea81014117ec6b73529a21626a9e1f829
• https://git.kernel.org/stable/c/05ac3754467363558a0a54ae4bb7c89b2c9574cf
• https://git.kernel.org/stable/c/1333eee56cdf3f0cf67c6ab4114c2c9e0a952026