CVE-2022-21546 is a vulnerability affecting Linux SCSI target subsystems (target_core_iblock and target_core_file). It’s rated 7.7 (High) on the CVSS 3.1 scale, primarily impacting system availability due to a crash (DoS). What’s unusual is that you don’t need kernel access or deep knowledge to trigger it—just a misused SCSI command with a special new-bit flag called NDOB.

Let’s break down what went wrong, who’s affected, and examine a real code snippet to show you where the bug lives. We'll also cover what makes this bug special and how it can be exploited by a low-privilege authenticated user.

What Is the NDOB Bit?

Starting in newer versions of the SBC (SCSI Block Commands) specification, a new bit called NDOB (No Data-Out Buffer) lets you signal to storage targets that there’s no actual data buffer to be written.

This is useful for certain maintenance commands, but it introduces risk: downstream code assumes the buffer is always there, and if it’s not, you can crash the underlying storage handler.

Where’s the Vulnerability?

Linux SCSI target drivers like target_core_iblock and target_core_file handle WRITE_SAME commands. If you run the command like this:

sg_write_same --ndob /dev/sgX

…then the SCSI command’s field se_cmd->t_data_sg (the “scatter-gather table”—basically, pointers to the user’s data) turns out to be NULL. But the kernel code doesn’t check for that—it just blindly tries to dereference it.

A simplified view in C of what goes wrong

// In target_core_iblock.c or target_core_file.c
struct se_cmd *cmd;
struct scatterlist *sgl = cmd->t_data_sg;

// Problem: NO null check!
void *src_addr = kmap_atomic(sgl[].page);
// If t_data_sg is NULL, this triggers a kernel panic!

As soon as you ask for sgl[] with a NULL t_data_sg, you dereference a bad pointer, and the kernel (and the service!) crashes.

Scope: Changed (impacts the environment)

- Confidentiality/Integrity: None (no data exposure or corruption)

Availability: High (DoS, crashes service)

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

Demonstration: Triggering the Crash

You can use the sg_write_same tool (comes with the sg3_utils package) to craft the offending command.

# Replace /dev/sgX with your actual SCSI device.
# This sets --ndob (no data out buffer)
sg_write_same --ndob /dev/sgX

Result:

Upstream maintainers fixed it by adding a check for the NDOB bit and handling NULL pointers

/* Pseudo-patch for target_core_iblock */
if (!cmd->t_data_sg && scsi_ndob(cmd)) {
    /* No data expected, skip or return OK */
    return ;
}
/* else: handle as usual */

You can review the exact fix in the kernel mailing list discussion and the commit in Linus Torvalds' tree.

Original References

- Oracle Security Advisory
- Red Hat Advisory
- Kernel Mailing List Patch Discussion
- CVSS v3 Calculator

Who's Affected

- Linux storage targets using target_core_iblock and target_core_file (common in SAN/iSCSI setups).

Upgrade your Linux kernel to a version where this is patched (check with your distro vendor).

- Don’t expose SCSI target interfaces to untrusted users/networks.

Conclusion

CVE-2022-21546 is a classic kernel bug in the way newer SCSI commands are handled. With a single, harmless-looking SCSI command, an attacker can crash Linux file/block storage targets if they're not patched.

Upgrade or mitigate as soon as you can—SCSI SANs often sit at the heart of your data center, and this one-liner can take them down.

Stay Safe

- Audit your SAN/iSCSI access.

Monitor for abnormal SCSI command usage from non-admin sources.

Exclusive write-up by [Your Name], 2024. Want to stay ahead? Read the upstream Kernel Security Changelog and check out the sg3_utils documentation to better understand your tools.

Timeline

Published on: 05/02/2025 22:15:15 UTC
Last modified on: 05/05/2025 20:54:19 UTC