CVE-2026-89963 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kexec_file: Fix null-ptr-def in extra size calculation
A static Sashiko AI review identified a potential NULL pointer dereference in kexec_extra_fdt_size_ppc64().
On platforms without any reserved memory regions, get_reserved_memory_ranges() can return 0 while leaving 'rmem' unallocated as NULL. Passing it directly leads to a kernel panic when evaluating 'rmem->nr_ranges'.
Add a NULL check for 'rmem' to prevent this crash.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the powerpc architecture's kexec_file subsystem represents a critical null pointer dereference issue that can lead to system instability or denial of service during the boot process. The flaw resides specifically within the function kexec_extra_fdt_size_ppc64, which is responsible for calculating the size required for extra device tree data when preparing a kernel image for execution via kexec on PowerPC platforms. This calculation involves determining the space needed to accommodate reserved memory regions that must be preserved during the transition from one kernel state to another. The root cause of this vulnerability stems from an incomplete validation check regarding the return value of get_reserved_memory_ranges, a helper function used to retrieve information about memory ranges marked as reserved by the firmware or previous boot stages.
Under normal operational conditions on systems with defined reserved memory regions, get_reserved_memory_ranges populates the output structure and returns a count greater than zero. However, on platforms where no such reserved memory regions are present, this function correctly returns zero but leaves the pointer variable rmem unallocated, effectively setting it to NULL. The original code logic proceeded directly to evaluate fields within the rmem structure, specifically accessing nr_ranges without verifying whether the pointer was valid. This oversight results in a null pointer dereference when the kernel attempts to read memory at address zero or an invalid location associated with the uninitialized pointer. In the context of Linux kernel development, such access violations trigger immediate panic conditions because they violate fundamental memory safety constraints and can corrupt critical system state information required for stable operation.
The operational impact of this vulnerability is significant during the kexec workflow, which is commonly used for fast reboot scenarios, live patching, or transitioning to a new kernel version without powering off hardware. If an administrator attempts to use kexec on a PowerPC system lacking reserved memory regions, the execution will fail catastrophically with a kernel panic rather than handling the edge case gracefully. This effectively denies service by preventing the intended boot sequence from completing successfully. The issue highlights a common class of defects where error paths or boundary conditions involving empty data sets are not adequately guarded against null references, leading to crashes that could be avoided through simple defensive programming practices such as explicit pointer validation before dereference operations.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes NULL Pointer Dereference, indicating improper handling of pointers that may point to invalid memory locations due to lack of initialization or failure checks. In terms of adversary behavior and detection frameworks like MITRE ATT&CK, while this is primarily an unintentional defect rather than a malicious exploit vector, similar null pointer dereferences can sometimes be leveraged in local privilege escalation attacks if they occur within contexts that allow for controlled memory state manipulation prior to the crash point. However, its primary relevance here remains as a stability and reliability flaw affecting system availability during critical boot operations.
To mitigate this vulnerability, developers must implement explicit NULL checks before accessing members of structures pointed to by dynamically allocated or conditionally assigned pointers. In this specific case, adding a conditional statement that verifies rmem is not NULL prior to evaluating rmem->nr_ranges ensures safe execution flow even when no reserved memory ranges exist. This fix prevents the kernel from attempting to access invalid memory addresses and allows the kexec process to proceed with zero extra size for reserved regions if applicable. Maintaining rigorous static analysis practices, such as those employed by tools like Sashiko AI or Coverity, helps identify these logical gaps early in the development cycle. Regular code reviews focusing on edge cases involving optional data structures are essential to prevent similar defects across other subsystems within the Linux kernel architecture.