CVE-2026-80710
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Aug 28, 2026
CISA due date
—
Cloudanix analysis
A math error in the Linux kernel code that handles certain mainframe storage devices can let a logged-in user take full control of the machine.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Integer truncation of a 64-bit buffer size calculation into a 32-bit variable causes kzalloc to allocate far less memory than requested; subsequent channel program construction then performs an out-of-bounds write past the undersized buffer in dasd_eckd_check_device_format.
Why it matters to the business
On s390 systems, a local attacker can achieve kernel-level code execution and full host compromise; the issue is confined to the dasd driver and does not affect other architectures.
How an attack unfolds
An attacker with local access supplies large start_unit/stop_unit values to the format-check path; the truncated size value yields a small allocation while the track count remains large, resulting in a linear buffer overflow during channel-program construction.
How to fix it
Apply the upstream fix that replaces the int declaration with size_t and uses check_mul_overflow to detect overflow and return -EINVAL; rebuild and deploy the updated kernel on all affected s390 systems.
How to confirm the fix worked
Inspect the dasd_eckd.c source for the corrected buffer-size computation using check_mul_overflow and size_t; confirm the change is present in the running kernel via /proc/version or kernel build logs.
Typical attack path
- Obtain local shell on an s390 Linux system with dasd devices
- Invoke dasd_eckd_check_device_format (directly or via a user-space utility) with caller-controlled track ranges large enough to trigger truncation
- Trigger the subsequent channel program build that writes beyond the undersized buffer
- Leverage the resulting kernel memory corruption for privilege escalation
How to detect it
Review kernel logs for oops/panic messages originating from dasd_eckd_check_device_format or channel-program routines; correlate with unusual format-check ioctl activity from unprivileged processes.
What your security team should do
- Prioritize kernel update on all s390 systems within normal change windows
- Limit untrusted local accounts on s390 hosts until patches are applied
- Monitor for future backports into distribution kernels
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|