CVE-2026-89457

What it actually does

A local race in the Linux s390 DASD driver leaves a window during dasd_generic_set_online() after the I/O discipline is attached but before check_device() allocates device->private. World-readable sysfs show/store handlers (including those built with DASD_DEFINE_ATTR()) invoke discipline callbacks that dereference that pointer. An unprivileged read in the window causes a kernel NULL pointer dereference and panics the host. Impact is availability only (host crash) on s390 systems bringing DASD devices online; no privilege escalation, remote reachability, or memory corruption for code execution is described.

Why it matters to the business

Linux on IBM Z hosts that use DASD can suffer an unplanned LPAR or guest crash if an unprivileged user hits the race while a volume is coming online, interrupting workloads that depend on those disks. The issue is not in CISA KEV, is not tied to ransomware, has exploit maturity none, and EPSS is ~0.0018 and flat over 30 days, so opportunistic mass exploitation is unlikely. Treat as a standard kernel availability fix for s390 DASD estates, with higher operational urgency on multi-tenant or developer LPARs where unprivileged users can read sysfs. Non-s390 architectures are unaffected.

How an attack unfolds

An unprivileged local user on a Linux s390 system watches for a DASD device-online sequence (administrator action, udev, or storage bring-up). In the short interval after the discipline is assigned and before private data is allocated, they read a world-readable DASD sysfs attribute. The handler calls a discipline callback that dereferences NULL device->private and the kernel panics. No remote vector, credentials, or payload are required; the outcome is denial of service only. No named APT groups or campaigns are associated with this issue, and there is no public exploit maturity.

How to fix it

Install a Linux kernel that includes the upstream s390/dasd change guarding sysfs discipline callbacks so they do not touch device->private until it is allocated. Use your distribution’s patched kernel package once the commit is backported (RHEL, SUSE, Ubuntu, Debian, and other s390 kernels). Exact upstream and package versions were not supplied with this record; match vendor advisories for “s390/dasd: Guard sysfs discipline callbacks against unallocated private data.” Reboot onto the patched kernel. Until then, limit unprivileged local logins on s390 DASD hosts and avoid bringing DASD devices online on multi-user systems when practical. x86_64/arm64 systems do not need this specific fix.

How to confirm the fix worked

Confirm architecture is s390/s390x and that DASD is in use; other architectures are not exposed. Verify the running kernel changelog or package errata contains the DASD sysfs private-data guard, then reboot and check the running kernel matches the patched package. Do not attempt to win the race on production systems. After patching, discipline sysfs handlers should return safely when private data is absent rather than oopsing.

Typical attack path

1. Obtain an unprivileged local account on a Linux s390 host that uses DASD.
2. Watch for or coincide with a DASD device being set online (discipline assigned, private data not yet allocated).
3. Read a world-readable DASD sysfs attribute whose show/store handler calls a discipline callback.
4. Kernel NULL-dereferences device->private and panics, taking the host down.

How to detect it

Successful abuse is a kernel panic, not persistent malware. Search kernel logs, journald, /var/log/kern.log, serial consoles, and kdump/vmcore around DASD online events for NULL pointer dereference with dasd or sysfs attribute handlers on the s390 call trace (including dasd_generic_set_online). Correlate with udev or admin device-online activity and unprivileged processes reading /sys/bus/ccw or /sys/block/dasd*. No threat-actor tooling is known. Missing logs or disabled kdump can hide a crash; lack of an oops does not prove the race was never attempted.

• Unable to handle kernel NULL pointer dereference
• dasd_generic_set_online
• DASD_DEFINE_ATTR
• /sys/bus/ccw/drivers/dasd-eckd
• /sys/bus/ccw/drivers/dasd-fba
• /sys/block/dasd
• Kernel panic - not syncing
• Call Trace: dasd

What your security team should do

• Inventory Linux on IBM Z (s390/s390x) with DASD and apply the patched kernel, then reboot.
• Deprioritize non-s390 fleets; they are not affected.
• Until patched, restrict unprivileged local access on DASD s390 hosts and treat device-online windows as sensitive.
• Align SLA with a normal kernel roll: not KEV, no ransomware use, EPSS ~0.0018 and unchanged.
• Enable kdump/vmcore and alert on dasd-related kernel oops/panic so a crash is captured if the race is hit.
• Track distro security advisories for the exact package that carries this DASD sysfs guard.