CVE-2021-47192

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: sysfs: Fix hang when device state is set via sysfs<br /> <br /> This fixes a regression added with:<br /> <br /> commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after<br /> offlinining device")<br /> <br /> The problem is that after iSCSI recovery, iscsid will call into the kernel<br /> to set the dev&amp;#39;s state to running, and with that patch we now call<br /> scsi_rescan_device() with the state_mutex held. If the SCSI error handler<br /> thread is just starting to test the device in scsi_send_eh_cmnd() then it&amp;#39;s<br /> going to try to grab the state_mutex.<br /> <br /> We are then stuck, because when scsi_rescan_device() tries to send its I/O<br /> scsi_queue_rq() calls -&gt; scsi_host_queue_ready() -&gt; scsi_host_in_recovery()<br /> which will return true (the host state is still in recovery) and I/O will<br /> just be requeued. scsi_send_eh_cmnd() will then never be able to grab the<br /> state_mutex to finish error handling.<br /> <br /> To prevent the deadlock move the rescan-related code to after we drop the<br /> state_mutex.<br /> <br /> This also adds a check for if we are already in the running state. This<br /> prevents extra scans and helps the iscsid case where if the transport class<br /> has already onlined the device during its recovery process then we don&amp;#39;t<br /> need userspace to do it again plus possibly block that daemon.