CVE-2021-47192: linux kernel — Fix

Description

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

Is your site exposed to CVE-2021-47192?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

5.3

MEDIUM

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Weakness Type (CWE)

CWE-667 CWE-667

Affected Products

Vendor	Product	Versions
linux	linux_kernel	5.4.143 — 5.4.162
linux	linux_kernel	5.10.61 — 5.10.82
linux	linux_kernel	5.13.13 — 5.15.5
linux	linux_kernel	All

References

Advisories & Patches

https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73 https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8 https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27 https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73 https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8 https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27

Frequently Asked Questions

What is CVE-2021-47192? +

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

How severe is CVE-2021-47192? +

CVE-2021-47192 has a CVSS v3.1 score of 5.3 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.

What products are affected by CVE-2021-47192? +

CVE-2021-47192 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2021-47192? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-1221

A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host …

CVE-2025-10151

Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects smartLink HW-PN: …

CVE-2026-54906 9.8

concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired …

CVE-2026-43215 8.8

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix locking usage for tcon fields We used to …

CVE-2026-31629 8.8

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() …

CVE-2026-62426 8.8

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To manage the …

CVE-2021-47192