scsi: core: sysfs: Fix hang when device state is set via sysfs
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- Low
- Impact type
- —
- Confidentiality · integrity · availability
- Low · None · None
- Fix status
- Partial Red Hat: 3 without a fix
Attack profile from CVSS 3.1 · CISA ADP. Fix status from CNA and Red Hat.
Summary
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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| Linux | Linux | 5.4.143 to before 5.4.162; 5.10.61 to before 5.10.82; 5.13.13 to before 5.14 | 5.4.162, 5.10.82, 5.14 | Patch available | CNA |
| Linux | Linux | 5.14 and later | 5.4.162, 5.10.82, 5.15.5, 5.16 | Patch available | CNA |
Remediation
- Fix · CNA Linux (Linux) Fixed in 5.4.162, 5.10.82, 5.14
- Fix · CNA Linux (Linux) Fixed in 5.4.162, 5.10.82, 5.15.5, 5.16
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Enterprise Linux 6 | Affected | No fix planned: Out of support scope |
| Red Hat Enterprise Linux 7 | Affected | No fix planned: Out of support scope |
| Red Hat Enterprise Linux 8 | Affected | No fix planned: Will not fix |
Not affected: 2 products
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
Timeline
- 2026-10-02 Threatist record created from CVE-2021-47192
- 2026-10-03 Alias added: GHSA-f834-hvgh-g5v9
References
More Linux Kernel vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
- TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
Sources
- CVE-2021-47192 · CVE Program
- CVE-2021-47192 · NVD
- FIRST EPSS
- GHSA-f834-hvgh-g5v9 · GitHub Advisory Database · CC BY 4.0
- CVE-2021-47192 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences