CVE-2026-89456

What it actually does

The s390 DASD driver does not copy proc_bytes from a finished Error Recovery Procedure (ERP) request back to the original I/O request in dasd_default_erp_postaction(). After a partial completion (for example an ESE read of a not-yet-allocated track), __dasd_cleanup_cqr() sees proc_bytes == 0 and completes the entire request instead of requeueing the unread remainder, so callers receive zero-filled data for storage that was never read. Confidentiality, integrity, and availability of DASD-backed I/O can all be affected because wrong data is delivered as a successful completion.

Why it matters to the business

Linux on IBM Z that uses DASD—especially thin-provisioned ESE volumes—can silently present zeros instead of real disk contents to filesystems, databases, and applications. That can corrupt transactions, poison backups, and cause hard-to-explain integrity failures on mainframe workloads. The flaw is local, high-complexity, not in CISA KEV, not tied to ransomware, and has no known in-the-wild exploitation about 30 days after publication, so mass-outbreak urgency is low; data-integrity risk on s390 DASD estates remains operationally serious wherever unpatched kernels still run.

How an attack unfolds

This is a local data-integrity failure, not a remote code-execution primitive, and no public exploit maturity or named threat actors are associated with it. An operator or attacker who already has low-privileged local access on s390 Linux would need to cause DASD I/O that partially completes and then traverses the ERP chain so proc_bytes is dropped. The kernel then reports the original request as fully complete and returns zeros for the unread portion. The same outcome can occur accidentally under genuine device recovery. Abuse would aim at corrupting or suppressing application-visible storage contents rather than escalating privileges by itself.

How to fix it

Upgrade s390 Linux kernels to a build that carries proc_bytes from the finished ERP request back to the original request in dasd_default_erp_postaction(), matching other per-request state. Use the vendor kernel package (distribution or OEM) that backports this DASD ERP fix, then reboot onto the patched kernel. There is no complete configuration-only workaround that restores partial-completion accounting; limiting ERP-heavy error conditions and ESE reads of unallocated tracks only reduces likelihood. Prioritize IBM Z hosts that actually use DASD/ESE.

How to confirm the fix worked

Confirm architecture s390x and that DASD (especially ESE) is in use, then verify the running kernel changelog or package notes include the DASD ERP proc_bytes propagation fix. After install and reboot, check uname/package version against the patched build. On a test volume, exercise partial-completion and ERP recovery (such as ESE reads of unallocated tracks) and confirm short transfers are accounted for and remainders are requeued rather than completed with zeros. Validate with application or filesystem checksums that known content is not replaced by zeros after recovery.

Typical attack path

1. Obtain local access on a Linux system running on IBM Z (s390) with DASD, particularly ESE or other thin-provisioned volumes.
2. Induce or wait for DASD I/O that only partially completes and is then recovered through the DASD ERP path.
3. Rely on ERP post-action omitting proc_bytes so the original request looks unprocessed.
4. Have kernel cleanup complete the full request instead of requeueing the remainder.
5. Use or persist the silently zero-filled unread region in userspace, filesystems, or applications without an I/O error being surfaced.

How to detect it

This bug does not drop a distinctive implant, C2 beacon, or host artifact. On s390 Linux with DASD, correlate kernel DASD ERP/recovery messages and sense data with application or database reports of unexpected zero regions, failed checksums, or silent short reads that still completed successfully. Review integrity jobs, backup verification, and filesystem checkers around those timestamps. Forensic comparison of affected files or DB pages against known-good copies may show logical zeros where content should exist. Lack of an I/O error despite truncated or zeroed ESE reads during recovery is consistent with this defect being hit, accidentally or otherwise. No KEV, ransomware, or named-actor context exists to hunt by campaign name.

What your security team should do

• Inventory Linux on IBM Z (s390x) and treat hosts with DASD, especially ESE volumes, as in-scope for this data-integrity fix.
• Patch and reboot to a kernel that propagates proc_bytes through DASD ERP post-action; do not wait for KEV or ransomware association.
• Until patched, strengthen application-level integrity checks (checksums, database page verification, backup validation) on DASD-backed data.
• Watch vendor s390 kernel advisories for the DASD ERP proc_bytes fix and track residual unpatched mainframe Linux.
• Hunt for integrity anomalies coinciding with DASD recovery rather than for a distinct malware implant; no named APT or ransomware campaign is linked to this CVE.