CVE-2021-47192: Vulnerability in Linux Linux
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.
AI Analysis
Technical Summary
CVE-2021-47192 is a medium-severity vulnerability in the Linux kernel's SCSI core subsystem related to sysfs device state management. The issue arises from a deadlock condition triggered when the device state is set via sysfs, specifically after iSCSI recovery operations. The vulnerability was introduced as a regression in a previous patch that fixed device capacity issues after offlining devices. During iSCSI recovery, the iscsid daemon attempts to set the device state to 'running' by invoking kernel functions that acquire the state_mutex. Concurrently, the SCSI error handler thread may attempt to acquire the same mutex while performing error handling commands. This leads to a deadlock because scsi_rescan_device() holds the mutex while attempting to send I/O requests, which are requeued due to the host being in recovery state, preventing the error handler from completing and releasing the mutex. The fix involves moving the rescan-related code to execute after releasing the state_mutex and adding checks to avoid redundant scans if the device is already in the running state. This prevents hangs and potential system instability during device recovery scenarios involving iSCSI. The vulnerability affects multiple Linux kernel commits identified by their hashes and was published on April 10, 2024. It has a CVSS 3.1 base score of 5.3 (medium), with network attack vector, low attack complexity, no privileges required, no user interaction, and limited confidentiality impact but no integrity or availability impact. No known exploits are reported in the wild at this time.
Potential Impact
For European organizations, this vulnerability could cause system hangs or deadlocks on Linux servers using iSCSI storage, particularly in environments with high availability or clustered storage configurations. The deadlock may lead to temporary unresponsiveness of storage devices, potentially disrupting critical applications relying on persistent storage access. While the vulnerability does not directly compromise data integrity or confidentiality, the resulting service interruptions could impact business continuity, especially in sectors like finance, healthcare, and manufacturing where Linux-based storage servers are common. Organizations using iSCSI for storage networking are at higher risk, as the issue specifically affects device state transitions during iSCSI recovery. The impact is primarily operational, causing potential downtime or degraded performance rather than data breaches or privilege escalations.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the patch fixing CVE-2021-47192. Since the vulnerability is related to specific kernel commits, verifying kernel versions against vendor advisories is critical. For environments where immediate patching is not feasible, administrators should monitor iSCSI device states and error handler logs for signs of hangs or deadlocks and consider temporarily disabling iSCSI recovery features if possible. Additionally, implementing robust monitoring and alerting on storage subsystem health can help detect early symptoms. Testing kernel updates in staging environments before production deployment is recommended to ensure compatibility. Organizations should also review their iSCSI configurations to minimize unnecessary device rescans and ensure that transport classes handle device onlining efficiently to reduce the risk of triggering the deadlock condition.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Italy, Spain
CVE-2021-47192: Vulnerability in Linux Linux
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.
AI-Powered Analysis
Technical Analysis
CVE-2021-47192 is a medium-severity vulnerability in the Linux kernel's SCSI core subsystem related to sysfs device state management. The issue arises from a deadlock condition triggered when the device state is set via sysfs, specifically after iSCSI recovery operations. The vulnerability was introduced as a regression in a previous patch that fixed device capacity issues after offlining devices. During iSCSI recovery, the iscsid daemon attempts to set the device state to 'running' by invoking kernel functions that acquire the state_mutex. Concurrently, the SCSI error handler thread may attempt to acquire the same mutex while performing error handling commands. This leads to a deadlock because scsi_rescan_device() holds the mutex while attempting to send I/O requests, which are requeued due to the host being in recovery state, preventing the error handler from completing and releasing the mutex. The fix involves moving the rescan-related code to execute after releasing the state_mutex and adding checks to avoid redundant scans if the device is already in the running state. This prevents hangs and potential system instability during device recovery scenarios involving iSCSI. The vulnerability affects multiple Linux kernel commits identified by their hashes and was published on April 10, 2024. It has a CVSS 3.1 base score of 5.3 (medium), with network attack vector, low attack complexity, no privileges required, no user interaction, and limited confidentiality impact but no integrity or availability impact. No known exploits are reported in the wild at this time.
Potential Impact
For European organizations, this vulnerability could cause system hangs or deadlocks on Linux servers using iSCSI storage, particularly in environments with high availability or clustered storage configurations. The deadlock may lead to temporary unresponsiveness of storage devices, potentially disrupting critical applications relying on persistent storage access. While the vulnerability does not directly compromise data integrity or confidentiality, the resulting service interruptions could impact business continuity, especially in sectors like finance, healthcare, and manufacturing where Linux-based storage servers are common. Organizations using iSCSI for storage networking are at higher risk, as the issue specifically affects device state transitions during iSCSI recovery. The impact is primarily operational, causing potential downtime or degraded performance rather than data breaches or privilege escalations.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the patch fixing CVE-2021-47192. Since the vulnerability is related to specific kernel commits, verifying kernel versions against vendor advisories is critical. For environments where immediate patching is not feasible, administrators should monitor iSCSI device states and error handler logs for signs of hangs or deadlocks and consider temporarily disabling iSCSI recovery features if possible. Additionally, implementing robust monitoring and alerting on storage subsystem health can help detect early symptoms. Testing kernel updates in staging environments before production deployment is recommended to ensure compatibility. Organizations should also review their iSCSI configurations to minimize unnecessary device rescans and ensure that transport classes handle device onlining efficiently to reduce the risk of triggering the deadlock condition.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-03-25T09:12:14.113Z
- Cisa Enriched
- true
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 682d9822c4522896dcbde08c
Added to database: 5/21/2025, 9:08:50 AM
Last enriched: 6/28/2025, 4:56:39 AM
Last updated: 7/26/2025, 8:11:22 PM
Views: 12
Related Threats
CVE-2025-49559: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22) in Adobe Adobe Commerce
MediumCVE-2025-49558: Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367) in Adobe Adobe Commerce
MediumCVE-2025-49557: Cross-site Scripting (Stored XSS) (CWE-79) in Adobe Adobe Commerce
HighCVE-2025-49556: Incorrect Authorization (CWE-863) in Adobe Adobe Commerce
HighCVE-2025-49555: Cross-Site Request Forgery (CSRF) (CWE-352) in Adobe Adobe Commerce
HighActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.