CVE-2023-53586

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: Fix multiple LUN_RESET handling

This fixes a bug where an initiator thinks a LUN_RESET has cleaned up running commands when it hasn't. The bug was added in commit 51ec502a3266 ("target: Delete tmr from list before processing").

The problem occurs when:

• We have N I/O cmds running in the target layer spread over 2 sessions.
• The initiator sends a LUN_RESET for each session.
• session1's LUN_RESET loops over all the running commands from both

sessions and moves them to its local drain_task_list.

• session2's LUN_RESET does not see the LUN_RESET from session1 because

the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists.

• sessions2's LUN_RESET will then complete with a successful response.
• sessions2's inititor believes the running commands on its session are

now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them.

• The commands do eventually complete on the backend and the target

starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.

Fix the bug by reverting the patch, and serialize the execution of LUN_RESETs and Preempt and Aborts.

Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list, because it turns out the original patch fixed a bug that was not mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second LUN_RESET and wait on it. Then the second reset will run core_tmr_drain_tmr_list and see the first reset and wait on it resulting in a deadlock.