CVE-2021-47192

scsi: core: sysfs: Fix hang when device state is set via sysfs

MEDIUM
5.3
CVSS Score
Published: April 10, 2024 at 06:56 PM UTC
Updated: June 17, 2026 at 04:16 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.3
Exploit prediction
EPSS 0.6%
SSVC
No known exploit

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 5.13.135.10.61 ≤ v < 5.10.825.13.13 ≤ v < 5.145.13.13 ≤ v < 5.15.55.14 ≤ v < 5.15.55.14 ≤ v < 5.165.4.143 ≤ v < 5.4.1625.10.615.13.135.16 rc15.4.14369aa1a1a569f5c6d554b59352130ef363342ed4c711459514e297d748f15ba1f5292a3276c3d1dd0c6751ce1a2a415a78e4f5b621628da03196b804cf0f82e2476f6adb9c7a0135cfab8091456990c99
Vendor states this is fixed in 4edd8cd4e86dd3047e5294bbefcc0a08f66a430f (fixed)
Vendor states this is fixed in a792e0128d232251edb5fdf42fb0f9fbb0b44a73 (fixed)
Vendor states this is fixed in bcc0e3175a976b7fa9a353960808adb0bb49ead8 (fixed)
Vendor states this is fixed in edd783162bf2385b43de6764f2d4c6e9f4f6be27 (fixed)
Vendor states this is fixed in 5.10.82 (unaffected)
Vendor states this is fixed in 5.14 (unaffected)
Vendor states this is fixed in 5.15.5 (unaffected)
Vendor states this is fixed in 5.16 (unaffected)
Vendor states this is fixed in 5.4.162 (unaffected)

References (4)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/4edd8cd4e86dd3047e5294bbefcc0a08f66a430f
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a792e0128d232251edb5fdf42fb0f9fbb0b44a73
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/bcc0e3175a976b7fa9a353960808adb0bb49ead8
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/edd783162bf2385b43de6764f2d4c6e9f4f6be27

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

5.3MEDIUMCISA-ADP
Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
LOW
Integrity
NONE
Availability
NONE
Vector?

Quick Info

StatusANALYZED
CWE
CWE-667

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card