CVE-2026-98399 in Linux
Summary
by MITRE • 10/14/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The Linux kernel vulnerability identified in the s390 architecture involves a critical NULL pointer dereference within the dump_reipl_run function during system crash handling procedures. This flaw specifically affects the stand-alone dump mechanism, which is distinct from kdump in its method of passing re-IPL parameter blocks. While kdump utilizes os_info for this purpose, stand-alone dumps rely on addresses and checksums located in the lowcore structure to determine how to handle subsequent initialization processes after a crash occurs. The root cause lies in the assumption that an IPL (Initial Program Load) parameter block is always present when initiating a re-IPL operation following a system dump.
The technical flaw manifests when certain boot methods, such as HMC FTP boot or QEMU direct kernel boot, do not provide an IPL parameter block to the operating system during initialization. In these scenarios, the function reipl_type_init correctly identifies the situation by selecting IPL_TYPE_UNKNOWN and leaving the variable reipl_block_actual set to NULL. However, the subsequent call to dump_reipl_run fails to account for this null state. Instead of checking for a valid pointer before proceeding, the code unconditionally attempts to dereference reipl_block_actual to populate lowcore fields required for potential future restarts. This unconditional access results in a kernel panic or undefined behavior due to the NULL reference.
The operational impact of this vulnerability is significant because it compromises the reliability of crash dump collection on affected s390 systems. Although the system might occasionally appear to function correctly by chance if address zero contains readable lowcore data, this is not guaranteed and depends heavily on memory layout at the time of the crash. When the dereference fails or produces invalid results, a zero IPL parameter block address along with an incorrect checksum may be stored in the lowcore structure. Consequently, when the system attempts to recover from the dump state using these corrupted parameters, it enters a disabled wait state rather than completing the process successfully. This effectively renders the stand-alone dumper ineffective for capturing diagnostic data necessary for post-mortem analysis of kernel faults.
From a classification perspective, this issue aligns with CWE-476, which describes a NULL pointer dereference vulnerability where software fails to check if a pointer is non-null before using it in an operation that requires valid memory access. In the context of the MITRE ATT&CK framework, this type of flaw can be leveraged for Denial of Service attacks by triggering kernel panics through specific boot configurations or crash scenarios, thereby disrupting system availability and preventing forensic analysis capabilities from functioning as intended.
The resolution involves explicitly handling cases where no re-IPL parameter block is available by storing a zero IPL parameter block address and checksum in the lowcore structure rather than attempting to dereference invalid memory addresses. This fix ensures that the stand-alone dumper completes its task of capturing system state without crashing, even when subsequent restart parameters are absent. The behavior remains consistent with previous stable releases for systems that do have valid re-IPL blocks, ensuring backward compatibility while eliminating the risk of NULL pointer exceptions during critical error handling paths in the s390 kernel subsystem.