CVE-2026-89458

What it actually does

On Linux s390 systems, a failed Extent Space Efficient (ESE) no-record-found read can be completed as success without zeroing the destination buffer. dasd_int_handler() calls ese_read() and then unconditionally marks the request DASD_CQR_SUCCESS. If dasd_eckd_ese_read() returns early (failed sense-data parse or track outside the requested range) the destination pages are left untouched, so the block layer is given stale or uninitialized memory instead of zeros. This is a local information-disclosure defect in the DASD interrupt completion path.

Why it matters to the business

Only IBM Z (s390) Linux hosts using ESE/thin-provisioned DASD are in scope, so blast radius is architecture-specific rather than fleet-wide. A successful trigger can expose residual kernel or previously stored page contents to a process that issued the read, with confidentiality impact rather than storage outage or data corruption. Exploitation probability is low (EPSS about 0.18% and flat over 30 days), exploit maturity is none, the issue is not in CISA KEV, and there is no reported ransomware use. Treat as a standard kernel confidentiality patch for mainframe Linux, not an emergency enterprise-wide event.

How an attack unfolds

An attacker who can issue block I/O against an ESE-enabled DASD volume arranges a read of an unallocated track. The DASD interrupt handler invokes ese_read(); if that helper fails before it zeros the destination, the handler still completes the command as successful. The block layer therefore returns leftover buffer contents to the caller instead of zeros. The attacker inspects that data for residual kernel or previously written material. Abuse requires local or guest ability to read the affected device; there is no known remote worm path, public exploit code, or named threat-actor campaign tied to this flaw.

How to fix it

Install a Linux kernel that includes the s390/dasd fix which checks the ese_read() return value and fails the request on the normal error path instead of forcing DASD_CQR_SUCCESS. Use your distribution’s IBM Z kernel security update once published (vendor kernels for RHEL, SLES, Ubuntu, and similar on s390). There is no complete configuration-only workaround. Until patched, restrict unprivileged access to DASD block devices and keep untrusted workloads off ESE volumes.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory includes the s390/dasd change “Do not complete a failed ESE read as successful.” In source or debug symbols, dasd_int_handler() must fail the request when ese_read() returns an error rather than setting DASD_CQR_SUCCESS. Match uname -r and package versions against the vendor advisory for s390 DASD. Do not attempt a live reproduction that reads unallocated ESE tracks, because that can itself surface residual memory.

Typical attack path

1. Obtain local or guest access on Linux running on s390 with ESE-provisioned DASD
2. Issue reads against unallocated ESE tracks (no-record-found path)
3. Cause ese_read() to fail before buffer zeroing (sense-data parse error or track outside range)
4. Receive a request completed as success that contains stale or uninitialized memory
5. Inspect returned data for residual kernel or previously stored contents

How to detect it

This defect completes I/O as success, so it leaves little distinctive compromise telemetry and no public malware, campaign, or actor IOCs. On s390 hosts, review kernel logs (dmesg, journalctl -k, distro kernel logs) for DASD sense-data parse failures, ESE-related errors, and unusual no-record-found handling around the time of suspicious reads of thin-provisioned volumes. Correlate with processes that had access to DASD block devices. Absence of those messages does not prove the leak was unused; forensic value is limited because leaked contents are returned to the caller rather than written to a distinctive path.

What your security team should do

• Inventory Linux on IBM Z and flag hosts that use ESE or thin-provisioned DASD
• Patch those kernels as soon as the s390/dasd ESE-read fix is available from the distro or upstream
• Until patched, limit who can open DASD block devices and isolate untrusted tenants from ESE volumes
• Track vendor kernel advisories; no CISA KEV due date applies
• Do not prioritize this above remotely wormable or KEV-listed kernel bugs given low EPSS, no known exploitation, and s390-only scope