CVE-2026-64297 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
module: decompress: check return value of module_extend_max_pages()
module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.
If the initial allocation fails, info->pages remains NULL and info->max_pages remains 0. Subsequent calls to module_get_next_page() will attempt to dynamically grow the array by calling module_extend_max_pages(info, 0) since info->used_pages is 0. This results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel oops.
Fix: add the missing error check after module_extend_max_pages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.
[Sami: Corrected the analysis in the commit message.]
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability resides within the Linux kernel's module loading subsystem, specifically in the decompression handling logic that manages dynamic memory allocation for module pages during the loading process. The flaw manifests when the kernel attempts to load kernel modules and dynamically extend memory arrays to accommodate module data structures. The issue stems from a critical oversight in error handling where the return value of the module_extend_max_pages() function is not properly validated. This function internally invokes kvrealloc() which can fail with -ENOMEM when memory allocation constraints are encountered, yet this failure condition is entirely ignored by the calling code.
The operational impact of this vulnerability becomes apparent during module loading scenarios where initial memory allocation fails and subsequent attempts to extend the page array trigger a dangerous code path. When the initial allocation fails, the module information structure maintains info->pages as NULL and info->max_pages as 0, creating a state where subsequent calls to module_get_next_page() attempt to grow the array by invoking module_extend_max_pages(info, 0). This particular call sequence results in kvrealloc being invoked with NULL pointer and zero size parameters, returning ZERO_SIZE_PTR which is erroneously treated as a successful allocation. The kernel then proceeds to dereference this ZERO_SIZE_PTR value, causing an immediate kernel oops and system crash.
This vulnerability aligns with CWE-476 which addresses null pointer dereference conditions in software systems, and demonstrates a classic pattern of improper error handling that can lead to denial of service or potentially more severe exploitation scenarios. The flaw is particularly concerning within the kernel's module loading path as it represents a direct attack surface where malicious actors could potentially trigger this condition through crafted module files, leading to system instability and potential privilege escalation opportunities. The fix implemented follows established patterns used throughout the kernel module loading codebase, specifically matching the error handling approach employed by all other kvrealloc() callers within the same execution path.
The remediation strategy involves adding a straightforward error check immediately after the module_extend_max_pages() function call, ensuring that any allocation failure results in immediate return from the calling function rather than proceeding with invalid memory operations. This approach maintains consistency with existing kernel coding practices and prevents the propagation of invalid memory references throughout the module loading pipeline. The solution addresses the root cause by ensuring proper error propagation through the call stack, preventing the kernel from attempting to dereference NULL or invalid memory pointers that would otherwise result in system crashes.
Security implications extend beyond simple denial of service as this vulnerability could potentially be exploited to gain unauthorized access to kernel memory spaces or manipulate module loading behavior. The ATT&CK framework would categorize this under privilege escalation techniques where an attacker might leverage such memory corruption vulnerabilities to elevate privileges within the kernel execution context. The fix ensures that the kernel maintains proper memory boundaries and prevents invalid pointer operations that could otherwise be leveraged in more sophisticated exploitation scenarios targeting the kernel's memory management subsystem.
This vulnerability highlights the critical importance of comprehensive error handling in kernel space operations where even seemingly minor oversights can result in catastrophic system failures. The Linux kernel development community has established rigorous standards for memory allocation error checking, and this fix reinforces those practices by ensuring that all dynamic memory operations within the module loading path follow consistent error handling patterns. The correction demonstrates how adherence to established kernel coding conventions prevents subtle but dangerous conditions that could otherwise remain undetected until exploited in production environments.
The implementation of this patch represents a defensive programming approach that aligns with security best practices for kernel development, ensuring that resource allocation failures are properly handled and propagated through the system rather than allowing invalid states to persist. This particular vulnerability serves as an example of why comprehensive testing and code review processes are essential in kernel development, as such subtle error handling issues can remain hidden for extended periods until discovered through careful analysis or exploitation attempts. The fix maintains backward compatibility while strengthening the kernel's resilience against memory allocation failures during module loading operations.