CVE-2023-53586

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix multiple LUN_RESET handling<br /> <br /> This fixes a bug where an initiator thinks a LUN_RESET has cleaned up<br /> running commands when it hasn&amp;#39;t. The bug was added in commit 51ec502a3266<br /> ("target: Delete tmr from list before processing").<br /> <br /> The problem occurs when:<br /> <br /> 1. We have N I/O cmds running in the target layer spread over 2 sessions.<br /> <br /> 2. The initiator sends a LUN_RESET for each session.<br /> <br /> 3. session1&amp;#39;s LUN_RESET loops over all the running commands from both<br /> sessions and moves them to its local drain_task_list.<br /> <br /> 4. session2&amp;#39;s LUN_RESET does not see the LUN_RESET from session1 because<br /> the commit above has it remove itself. session2 also does not see any<br /> commands since the other reset moved them off the state lists.<br /> <br /> 5. sessions2&amp;#39;s LUN_RESET will then complete with a successful response.<br /> <br /> 6. sessions2&amp;#39;s inititor believes the running commands on its session are<br /> now cleaned up due to the successful response and cleans up the running<br /> commands from its side. It then restarts them.<br /> <br /> 7. The commands do eventually complete on the backend and the target<br /> starts to return aborted task statuses for them. The initiator will<br /> either throw a invalid ITT error or might accidentally lookup a new<br /> task if the ITT has been reallocated already.<br /> <br /> Fix the bug by reverting the patch, and serialize the execution of<br /> LUN_RESETs and Preempt and Aborts.<br /> <br /> Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,<br /> because it turns out the original patch fixed a bug that was not<br /> mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second<br /> LUN_RESET and wait on it. Then the second reset will run<br /> core_tmr_drain_tmr_list and see the first reset and wait on it resulting in<br /> a deadlock.