CVE-2026-97951: scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix hang for aborted WRITEPENDING commands
When a LUNRESET aborts a WRITE command that is in the TRANSPORTWRITEPENDING state, the target core sets CMDTABORTED and waits for the frontend to finish processing.
If the initiator subsequently sends the remaining dataout PDUs, iscsitcheckdataouthdr() catches the payload, stops the dataout timer if the sequence is final and finally dumps the data. However, the iSCSI target doesn't trigger the completion process for these aborted commands. Because of this, the abort path hangs indefinitely in targetputcmdandwait(), leading to a deadlocked target worker thread.
Fix this by explicitly calling targetcompletecmd() when the final dataout PDU is received for an aborted WRITE command. targetcompletecmd() detects the CMDTABORTED flag and cleanly routes the command into targetabortwork, allowing the abort completion to successfully unblock.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this hang?
Systems using the Linux kernel iSCSI target are exposed when they process WRITE commands that can be aborted by a LUN_RESET while in the TRANSPORT_WRITE_PENDING state. The issue affects target-side processing rather than an iSCSI initiator.
What sequence is required to trigger the deadlock?
A LUN_RESET must abort a WRITE command while it is waiting for write data, and the initiator must then send the remaining Data-Out PDUs, including the final PDU. Without completion being triggered for that aborted command, the abort path waits indefinitely and a target worker thread deadlocks.
How can I tell whether the issue is occurring?
The observable condition described is a target worker thread blocked indefinitely in target_put_cmd_and_wait() after an aborted WRITE_PENDING command receives its final Data-Out PDU. This can manifest as an iSCSI target-side hang during that abort sequence.
What does the fix change?
The fix calls target_complete_cmd() when the final Data-Out PDU arrives for an aborted WRITE command. That function recognizes the aborted-command flag, routes processing to target_abort_work, and allows the waiting abort path to complete.