In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev->use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.
Security readout for executives and security teams
Plain-English summary
A Linux kernel SCSI routine mishandled buffer sizes when querying storage device settings. In certain kernel and driver paths, that could corrupt adjacent kernel memory. The source bundle gives no CVSS score and no evidence of active exploitation, so urgency should be driven by kernel exposure and storage workload criticality.
Executive priority
Treat this as a kernel maintenance issue with moderate urgency. Prioritize critical Linux infrastructure and storage-dependent systems, but do not assume emergency exploitation without additional evidence.
Technical view
The flaw is in scsi_mode_sense() buffer length handling. MODE SENSE(10) allocation length was truncated to one byte, and undersized caller buffers could be zero-filled beyond their bounds. The kernel fix uses proper 16-bit encoding, rejects too-small buffers, prefers MODE SENSE(10) for lengths over 255 bytes, and adds bounds checks.
Likely exposure
Exposure is limited to Linux systems using affected kernel versions and SCSI/storage code paths. The source bundle names Linux kernel versions including 2.6.12, 5.15.5, and 5.16, but distro-specific package mapping requires vendor confirmation.
Exploitation context
The provided sources do not report exploitation in the wild, and this CVE is not marked KEV. The bundle describes a kernel memory corruption condition but does not provide attack prerequisites, privilege requirements, or reachable product-specific scenarios.
Researcher notes
Evidence supports a memory corruption bug in Linux SCSI core length handling. Missing data includes CVSS, CWE classification, exploitability conditions, and distribution-specific fixed versions. Validation should focus on kernel provenance and inclusion of the stable commits.
Mitigation direction
Update to a Linux kernel containing the referenced stable fixes.
Check distribution advisories for the exact fixed kernel package.
Prioritize storage-heavy servers, virtualization hosts, and systems using SCSI devices.
Schedule reboot or live-patching according to vendor kernel guidance.
Avoid inventing local workarounds; follow kernel or distro guidance.
Validation and detection
Inventory Linux kernel versions across affected server fleets.
Confirm whether deployed kernels include the referenced stable commits.
Map distro package versions to upstream kernel fixes.
Review exposure of systems using SCSI or storage driver paths.
Document any exceptions awaiting vendor-fixed packages.
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-47182 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.