scsi: target: tcm_loop: Drain commands in target_reset handler
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
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.203, 6.1.168, 6.12.81, 6.18.22, 6.19.12, 6.6.134
- CVEs
- CVE-2026-43054
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 00:12 UTC · Revision 1
Source evidence
scsi: target: tcm_loop: Drain commands in target_reset handler
core-osv · Original sourcePublished 1 May 2026, 14:15 UTC
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
osv:CVE-2026-43054
Kernel
Fixed versions: 5.15.203, 6.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12
Complete source record
{
"id": "967ff5a092a163c5ece22c77060931f910e4537f49bc0ce0ad0044c03fb6d865",
"url": "https://osv.dev/vulnerability/CVE-2026-43054",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "scsi: target: tcm_loop: Drain commands in target_reset handler",
"summary": "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 ",
"evidence": "osv:CVE-2026-43054",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.203",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.168",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.134",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.81",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.22",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.12",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-43054",
"aliases": [
"CVE-2026-43054"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "e0eb5d38b732b011cd9ed5b1bf9f59b83c2500d3"
},
{
"fixed": "757c43c692294cdfad31390accc0e90429b2ef8a"
},
{
"fixed": "103f79e4949513247d763c6e7f3cbbf62017afdf"
},
{
"fixed": "15f5241d5a52364a7e7867b49128b0442dbcad9d"
},
{
"fixed": "7cbd69aaa507b1245240a28022bf5da0f07c68d9"
},
{
"fixed": "a836054ea81014117ec6b73529a21626a9e1f829"
},
{
"fixed": "05ac3754467363558a0a54ae4bb7c89b2c9574cf"
},
{
"fixed": "1333eee56cdf3f0cf67c6ab4114c2c9e0a952026"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-43054.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.13.0"
},
{
"fixed": "5.15.203"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.168"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.134"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.81"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.22"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.12"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-43054.json"
}
}
],
"modified": "2026-10-28T02:30:32.648677035Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/05ac3754467363558a0a54ae4bb7c89b2c9574cf",
"https://git.kernel.org/stable/c/103f79e4949513247d763c6e7f3cbbf62017afdf",
"https://git.kernel.org/stable/c/1333eee56cdf3f0cf67c6ab4114c2c9e0a952026",
"https://git.kernel.org/stable/c/15f5241d5a52364a7e7867b49128b0442dbcad9d",
"https://git.kernel.org/stable/c/757c43c692294cdfad31390accc0e90429b2ef8a",
"https://git.kernel.org/stable/c/7cbd69aaa507b1245240a28022bf5da0f07c68d9",
"https://git.kernel.org/stable/c/a836054ea81014117ec6b73529a21626a9e1f829",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43054.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-43054",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43054.json"
}
},
"related_cves": [
{
"value": "CVE-2026-43054",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 499318,
"published_at": "2026-05-01T14:15:47.396+00:00"
}