Description

In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:51.727Z",
  "pubdate": "2026-08-15T13:17:51.727Z",
  "executiveSummary": "An out-of-bounds write vulnerability exists in the Linux kernel SCSI debug driver (scsi_debug), specifically within the REPORT ZONES command handling function resp_report_zones(). This flaw is classified as an integer overflow leading to a buffer allocation mismatch and subsequent out-of-bounds memory write. The vulnerability impacts the Linux kernel when utilizing the scsi_debug module, posing a risk of kernel panic, denial of service, or potentially arbitrary memory corruption. Risk implications are generally restricted to environments loading the scsi_debug module, often used for testing and debugging storage subsystems. Attacker capabilities require local access or the ability to issue crafted SCSI commands to the target driver to trigger the anomalous allocation length. Exploitation relies on specific boundary values for the allocation length parameter that trigger arithmetic truncation during memory allocation on 32-bit architectures, bypassing size validation checks.",
  "technicalDetails": "The vulnerability resides in the resp_report_zones() function within the scsi_debug driver of the Linux kernel. The root cause stems from improper integer handling and alignment calculations of the allocation length (alloc_len) provided in the SCSI Command Descriptor Block (CDB). The v3 fix attempted to normalize alloc_len by rounding it up using the ALIGN() macro before deriving the descriptor count via the formula rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD), followed by calculating arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1).\nFor allocation lengths ranging from 0xFFFFFFC1 to 0xFFFFFFFF, the ALIGN() macro rounds the value up to 0x100000000. Consequently, the resulting arr_len becomes 4 GB. On 32-bit systems, the size_t type utilized by kzalloc() is 32 bits wide, which truncates the 0x100000000 value to 0. The subsequent invocation of kzalloc(0) returns ZERO_SIZE_PTR. This returned pointer successfully bypasses the null check (!arr), allowing the code to compute desc = arr + 64. When the execution flow enters the zone-reporting loop, dereferencing this calculated pointer results in an out-of-bounds write or an immediate kernel panic due to invalid memory access.\nThe step-by-step attack flow involves an actor or test harness submitting a crafted REPORT ZONES SCSI command with an allocation length in the vulnerable upper boundary range (0xFFFFFFC1 through 0xFFFFFFFF). The vulnerable component, resp_report_zones(), processes the input and performs the flawed alignment calculation. Due to arithmetic overflow and type truncation on 32-bit systems, a zero-byte allocation size is passed to the memory allocator. The allocation check is evaded, and subsequent loop iterations write zone descriptors to invalid memory offsets relative to the base pointer, corrupting kernel memory or crashing the system."
}