CVE-2026-43054

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

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*

History

11 Nov 2026, 23:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: scsi: target: tcm_loop: Drenar comandos en el gestor target_reset tcm_loop_target_reset() viola el contrato SCSI EH: devuelve SUCCESS sin drenar ningún comando en curso. La documentación SCSI EH (scsi_eh.rst) requiere que cuando un gestor de reinicio devuelve SUCCESS, el controlador haya hecho que las capas inferiores ’olviden los scmds con tiempo de espera agotado’ y esté listo para nuevos comandos. Todos los demás SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug, mpi3mr) aplican esto drenando o completando los comandos pendientes antes de devolver SUCCESS. Debido a que tcm_loop_target_reset() no drena, el SCSI EH reutiliza las estructuras scsi_cmnd en curso para comandos de recuperación (p. ej., TUR) mientras el núcleo de destino todavía tiene trabajo de finalización asíncrono en cola para el antiguo se_cmd. El memset en queuecommand pone a cero se_lun y lun_ref_active, lo que hace que transport_lun_remove_cmd() omita su percpu_ref_put(). La referencia LUN filtrada impide que transport_clear_lun_ref() se complete, dejando el desvinculado de LUN de configfs colgado para siempre en estado D: INFO: tarea rm:264 bloqueada durante más de 122 segundos. rm D 0 264 258 0x 00004000 Rastro de llamada: __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 Solucione esto haciendo que tcm_loop_target_reset() realmente drene los comandos: 1. Emitir TMR_LUN_RESET a través de tcm_loop_issue_tmr() para drenar todos los comandos que el núcleo de destino conoce (aquellos que aún no son CMD_T_COMPLETE). 2. Usar blk_mq_tagset_busy_iter() para iterar todas las solicitudes iniciadas y flush_work() en cada se_cmd - esto drena cualquier trabajo de finalización diferido para comandos que ya tenían CMD_T_COMPLETE establecido antes del TMR (que el TMR omite a través de __target_check_io_state()). Este es el mismo patrón utilizado por mpi3mr, scsi_debug y libsas para drenar comandos pendientes durante el reinicio.

Information

Published : 2026-05-01 15:16

Updated : 2026-11-11 23:10


NVD link : CVE-2026-43054

Mitre link : CVE-2026-43054

CVE.ORG link : CVE-2026-43054


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-772

Missing Release of Resource after Effective Lifetime