CVE-2026-98400 in Linux
Summary
by MITRE • 10/14/2026
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.
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 vulnerability identified in the Linux kernel for s390 architecture involves a NULL pointer dereference that occurs during the kdump process when specific IPL types are utilized. This issue specifically affects scenarios where the system boots using methods such as HMC FTP boot or QEMU direct kernel boot, which do not provide an IPL parameter block to the operating system. In these cases, the function reipl_type_init() correctly identifies the situation by selecting IPL_TYPE_UNKNOWN and leaving the variable reipl_block_actual in a NULL state. The core of the vulnerability lies in how the crash dump mechanism handles this uninitialized or null reference during the shutdown sequence for capturing memory dumps.
The root cause is traced to a change introduced in commit 3b9678472bab, titled s390/ipl: correct kdump reipl block checksum calculation. Prior to this commit, the os_info entry containing the re-IPL parameter block was only added for IPL types that had successfully initialized reipl_block_actual. This conditional approach effectively prevented any attempt to access a NULL pointer when no valid block existed. However, the aforementioned commit moved the update of the os_info structure into the machine_crash_shutdown() function, making it unconditional regardless of whether a valid re-IPL parameter block was present. Consequently, the function set_os_info_reipl_block() attempts to dereference reipl_block_actual even when it is NULL, leading to a potential kernel panic or undefined behavior during crash dump collection.
From an operational perspective, this vulnerability impacts the reliability and stability of the kdump mechanism on s390 systems using specific boot methods. While the system might occasionally appear to function correctly due to chance, such as address zero containing readable lowcore data that allows the empty os_info entry to be ignored by the dump kernel, this behavior is not guaranteed across all hardware configurations or memory states. The lack of a reliable fallback mechanism means that in many instances, attempting to capture a crash dump under these conditions could result in a secondary failure, preventing the collection of critical diagnostic information needed for post-mortem analysis. This undermines the effectiveness of kdump as a tool for debugging kernel crashes on affected platforms.
The resolution involves modifying the logic within machine_crash_shutdown() or related functions to check if reipl_block_actual is non-NULL before attempting to update os_info with the re-IPL parameter block data. By skipping this update when no valid re-IPL parameter block is available, the system ensures that kdump can proceed safely without triggering a NULL pointer dereference. This allows the dump kernel to collect the necessary memory state and reboot the system appropriately, maintaining the integrity of the crash reporting process even for IPL types that do not support standard parameter blocks.
This issue aligns with CWE-476, which describes a NULL Pointer Dereference vulnerability where software incorrectly handles a null pointer value, potentially leading to crashes or unexpected behavior. In terms of attack vectors and defensive mapping, this falls under the broader category of reliability issues rather than direct exploitation for privilege escalation, though it can be leveraged in denial-of-service scenarios if an attacker can induce a kernel crash on affected systems. The fix ensures that the system adheres to robust error handling practices by validating pointers before dereferencing them, thereby enhancing the overall resilience of the s390 architecture's crash dump infrastructure against edge cases involving non-standard boot configurations.