Cloudanix VulnDB

CVE-2026-98399

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux on certain IBM mainframe systems can stop memory dumps from finishing properly after a crash when the system was started in specific ways, leaving the machine stuck.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

NULL pointer dereference in dump_reipl_run() when reipl_block_actual remains NULL for IPL types such as HMC FTP boot or QEMU direct kernel boot; the function unconditionally dereferences the pointer while writing lowcore fields, storing a zero IPL parameter block address and checksum.

Why it matters to the business

On s390 Linux systems, stand-alone kernel dumps triggered after crashes may fail to complete or leave the system in a disabled wait state, delaying post-incident analysis and recovery on affected mainframe and virtualized deployments.

How an attack unfolds

An attacker with the ability to induce a kernel panic on an s390 system booted without a valid IPL parameter block (for example via QEMU direct kernel boot) causes dump_reipl_run() to dereference a NULL pointer; the resulting lowcore state makes the stand-alone dumper halt after writing the dump, preventing further analysis.

How to fix it

Apply the upstream kernel patch that explicitly stores a zero IPL parameter block address and checksum when no re-IPL parameter block is available; rebuild and deploy the updated kernel on all s390 systems.

How to confirm the fix worked

Inspect the s390/ipl.c source for the conditional handling around reipl_block_actual before dereference; confirm the fixed kernel version is running via uname -r and that stand-alone dumps succeed on HMC FTP and QEMU direct boot configurations.

Typical attack path

  1. Gain code execution or trigger conditions leading to kernel panic on s390
  2. Ensure the system was booted via HMC FTP or QEMU direct kernel boot so reipl_block_actual is NULL
  3. Observe the stand-alone dumper enter disabled wait after the dump completes

How to detect it

Review kernel crash logs and stand-alone dump output for entries showing IPL_TYPE_UNKNOWN followed by a disabled wait state; correlate with boot method indicators in system logs or hypervisor configuration.

What your security team should do

  • Prioritize patching s390 Linux kernels within the next maintenance window
  • Test stand-alone dump functionality on representative HMC and QEMU boot setups after upgrade
  • Monitor upstream stable branches for backports of the fix

The record

In the Linux kernel, the following vulnerability has been resolved: s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes the dump and halts, while valid re-IPL parameter blocks continue to be handled as before.

Affected packages

Ecosystem Package Introduced Fixed