Cloudanix VulnDB

CVE-2026-98400

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

On certain IBM Z systems a crash dump might fail or cause further problems when the system was started in specific ways without extra boot information.

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

What it actually does

NULL pointer dereference in set_os_info_reipl_block() when reipl_block_actual is NULL for IPL_TYPE_UNKNOWN during machine_crash_shutdown() on s390 systems without an IPL parameter block.

Why it matters to the business

Crash dump collection may fail or trigger a kernel panic on certain s390 boot configurations, delaying incident response and forensic analysis after system crashes.

How an attack unfolds

An attacker triggers a kernel crash on an affected s390 system booted without a re-IPL parameter block (such as via HMC FTP or QEMU direct boot); the unconditional os_info update then dereferences a NULL pointer, potentially causing a panic instead of a clean kdump.

How to fix it

Apply the upstream kernel fix that skips the os_info update when no re-IPL parameter block is available; rebuild and deploy the patched kernel on s390 systems.

How to confirm the fix worked

Confirm the patch is present by checking for the conditional guard around set_os_info_reipl_block() in machine_crash_shutdown(); test kdump on HMC FTP and QEMU direct-boot configurations.

Typical attack path

  1. Identify or induce a crash condition on s390 Linux without re-IPL parm block
  2. Reach machine_crash_shutdown() which now unconditionally calls set_os_info_reipl_block()
  3. Dereference of reipl_block_actual (NULL) occurs, leading to NULL dereference or unstable kdump behavior

How to detect it

Review kernel crash logs and kdump output for NULL dereference in s390 ipl code paths; inspect os_info entries generated during shutdown on affected IPL types.

What your security team should do

  • Prioritize patching s390 kernels within normal change windows given low EPSS and no KEV listing
  • Verify kdump functionality after upgrade on representative boot types
  • Monitor for future s390 ipl-related changes in stable kernel updates

The record

In the Linux kernel, the following vulnerability has been resolved: s390/ipl: Fix NULL deref in kdump without re-IPL parm block 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. kdump passes the re-IPL parameter block to the dump kernel through os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation"), the os_info entry was added only for IPL types which initialized reipl_block_actual. That commit moved the os_info update to machine_crash_shutdown(), making it unconditional. As a result, set_os_info_reipl_block() dereferences reipl_block_actual for IPL_TYPE_UNKNOWN. This may happen to work by chance when address zero contains readable lowcore data and the resulting empty os_info entry is ignored by the dump kernel. Skip the os_info update when no re-IPL parameter block is available. Kdump then collect the dump and reboot without setting re-IPL parameter block.

Affected packages

Ecosystem Package Introduced Fixed