Description

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix undersized format-check buffer fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:56.633Z",
  "pubdate": "2026-08-28T08:16:56.633Z",
  "executiveSummary": "A critical integer truncation vulnerability exists in the Linux kernel's s390 DASD driver within the dasd_eckd_check_device_format function.\nThe vulnerability arises from an improper data type assignment during buffer size calculation, where a 64-bit result is truncated into a 32-bit signed integer.\nThis flaw leads to a heap-based buffer overflow, as kzalloc() allocates insufficient memory compared to the actual data processing requirements.\nAn attacker capable of triggering the format check process with specific parameters can cause memory corruption, potentially leading to system instability, kernel panics, or arbitrary code execution.\nThe impact is significant, as it affects the reliability and security of storage management on s390-based Linux systems.\nExploitation requires the ability to influence the track range parameters provided to the device driver.",
  "technicalDetails": "The vulnerability is located in the dasd_eckd_check_device_format function within the s390 DASD driver. The root cause is a type mismatch when calculating the size of the format-check buffer.\nThe expression 'trkcount * rpt_max * sizeof(struct eckd_count)' is evaluated using 64-bit arithmetic; however, the resulting value is stored in 'fmt_buffer_size', which is declared as a 32-bit 'int'.\nIf the input parameters 'start_unit' and 'stop_unit' (which define 'trkcount') are sufficiently large, the calculation can result in a value that exceeds the maximum capacity of a signed 32-bit integer. This results in silent truncation, where the high-order bits are discarded.\nThe attack flow proceeds as follows: First, an attacker provides a crafted range of tracks that causes the multiplication result to wrap around during the truncation process. Second, this erroneously small value is passed to kzalloc(), which allocates a memory block much smaller than the actual amount of data to be written.\nThird, the subsequent channel program build process operates using the original, untruncated track count. As the driver attempts to fill the buffer, it writes beyond the allocated boundaries of the heap memory.\nBecause kzalloc is used, this creates a heap-based buffer overflow. This allows for the corruption of adjacent kernel memory structures, which may lead to privilege escalation or a denial-of-service condition via a kernel crash.\nThe vulnerability is primarily accessible to users or processes with sufficient privileges to interact with the dasd storage device interface. It does not require remote network access but targets a local kernel-space memory management flaw."
}