LiveActive security incident?Get immediate response
CVE Record

CVE-2021-47192: scsi: core: sysfs: Fix hang when device state is set via sysfs

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.

MediumCVSS 5.3Not KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel flaw can make SCSI device recovery hang when a device state is changed through sysfs during iSCSI recovery. The business concern is service interruption on systems that depend on SCSI or iSCSI storage. The source rates it medium, and there is no KEV evidence of active exploitation.

Executive priority

Treat as a moderate operational reliability issue for Linux storage infrastructure. Prioritize patching on systems where SCSI or iSCSI recovery failures could affect critical services, but do not treat it as confirmed actively exploited based on this bundle.

Technical view

The issue is a SCSI core deadlock: scsi_rescan_device() was called while state_mutex was held. During recovery, error handling could need the same mutex while I/O is requeued because the host remains in recovery. The fix moves rescan work after releasing the mutex and avoids redundant scans when already running.

Likely exposure

Exposure is most likely on Linux systems using affected kernel versions or downstream kernels containing the referenced regression, especially with SCSI or iSCSI storage recovery paths. Exact exposure requires mapping distro kernel builds to the listed upstream stable fixes.

Exploitation context

The bundle does not show KEV listing or active exploitation. The described trigger is a recovery-path deadlock tied to sysfs device-state handling. The CVSS vector says network, no privileges, and no user interaction, but the provided text does not explain a remote exploitation path.

Researcher notes

The evidence supports a kernel deadlock fix, not weaponized exploitation. The affected version data mixes commits and kernel versions, so downstream validation should rely on vendor advisories or commit backport checks. The source CVSS vector is broader than the narrative trigger details.

Mitigation direction

  • Apply vendor kernel updates containing the referenced stable fixes.
  • Prioritize systems using SCSI or iSCSI storage recovery workflows.
  • Check Linux distribution advisories for backported fixes.
  • Avoid direct wrangler deploy equivalents are not relevant here; follow kernel vendor maintenance procedures.

Validation and detection

  • Inventory Linux kernel versions on storage-dependent systems.
  • Map distro kernels to the upstream fixed commits or advisories.
  • Review logs for SCSI or iSCSI recovery hangs around device state changes.
  • Confirm patched kernels no longer contain the referenced regression behavior.
Prepared
Confidence
high
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2021-47192 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Medium
CVSS
5.3 (3.1)
Known Exploited
No
Published

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

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

1CVSS vectors
3Timeline events
2ADP providers
5Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

CVSS vector scores

1 official score

We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.

ScoreVersionSeverityVectorExploitImpactSource
5.3CVSS 3.1MediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N3.91.4CISA-ADP

Vulnerability scoring details

Base CVSS 3.1 score

5.3Medium
CVSS 3.1 vector shape for CVE-2021-47192Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

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

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
cvssV3_1other:ssvc
CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux69aa1a1a569f5c6d554b59352130ef363342ed4c, 711459514e297d748f15ba1f5292a3276c3d1dd0, f0f82e2476f6adb9c7a0135cfab8091456990c99, f0f82e2476f6adb9c7a0135cfab8091456990c99, c6751ce1a2a415a78e4f5b621628da03196b804cunaffected
LinuxLinux5.14, 0, 5.4.162, 5.10.82, 5.15.5, 5.16affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.