GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux LIO iSCSI target: LUN_RESET on a WRITE_PENDING command deadlocks the target worker thread

UnscoredCVE-2026-97951Kernel, userspace & hypervisorcurated

Impact

When a LUN_RESET aborts a WRITE command sitting in TRANSPORT_WRITE_PENDING, the target core sets CMD_T_ABORTED and waits for the frontend. The iSCSI frontend consumed and dumped the remaining dataout PDUs but never triggered completion, so the abort path blocked forever in target_put_cmd_and_wait() and deadlocked a target worker thread. For an operator this is a hang in the box that exports block storage over iSCSI - one stuck worker degrades or stalls LUN service to every initiator behind it, and clearing it means rebooting the target host, which takes the storage away from every node mounting it. The trigger is an ordinary initiator sequence (a LUN reset followed by the remaining dataout PDUs), so any initiator that can talk to the portal can provoke it. No CVSS score is in the record.

Who can reach it

Any iSCSI initiator that can reach the target portal and is permitted to the LUN - so authentication depends on your ACL and CHAP configuration, and on a flat storage VLAN that is effectively anyone on that network. No local access to the target host is needed.

What to do

Update the target host to a stable kernel that calls target_complete_cmd() for the final dataout PDU of an aborted WRITE (four stable commits listed) and reboot it; LIO lives in the kernel, so there is no daemon restart that fixes this and the storage export goes away for the duration. Plan for failover of anything mounting those LUNs. No distro fixed version is named in the record.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.