CVE-2021-47182

What it actually does

Improper buffer length handling in scsi_mode_sense() truncates MODE SENSE(10) allocation length fields above 255 bytes and can zero-fill memory beyond caller-provided buffers when len is below minimum thresholds, enabling kernel memory corruption.

Why it matters to the business

Linux systems using SCSI storage may experience kernel panics, data corruption, or local privilege escalation, disrupting servers, storage arrays, and embedded devices that rely on the affected kernel code paths.

How an attack unfolds

An attacker with local access crafts or intercepts calls to scsi_mode_sense() with either oversized or undersized len values; the kernel then either truncates CDB fields or writes past buffer bounds, corrupting adjacent kernel memory that can be leveraged for code execution or denial of service.

How to fix it

Apply the upstream fix that uses put_unaligned_be16() for the MODE SENSE(10) allocation length, enforces minimum len checks, prefers MODE SENSE(10) for buffers > 255 bytes, and adds a 65535-byte upper bound; rebuild and boot the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the commit that introduces get_unaligned_be16() usage and the len bounds checks in drivers/scsi/scsi_lib.c; run kernel self-tests exercising scsi_mode_sense() with varied buffer sizes and verify no memory corruption occurs.

Typical attack path

1. Obtain local user or process execution on a Linux host with SCSI devices
2. Trigger or supply parameters to scsi_mode_sense() via ioctl, block layer, or device driver paths with len < 4/8 or len > 255
3. Cause either truncation of the 16-bit allocation length or out-of-bounds zero-fill
4. Leverage resulting kernel memory corruption for privilege escalation or crash

How to detect it

Review kernel logs for oops/panic traces mentioning scsi_mode_sense or MODE SENSE buffer handling; inspect audit logs for unusual SCSI ioctl activity from non-root processes; correlate with any post-2021 kernel updates that address this class of memory issue.

What your security team should do

• Prioritize kernel updates on all Linux hosts that expose SCSI storage, especially those reachable by untrusted local users
• Audit custom device drivers or user-space tools that directly invoke mode sense operations
• Monitor for kernel oops or panic reports referencing scsi_mode_sense after the patch date