{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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.",
  "id": "DEBIAN-CVE-2026-43054",
  "modified": "2026-09-14T16:47:45.155858300Z",
  "published": "2026-05-01T15:16:51.910Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-43054"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-43054"
  ]
}