CVE-2026-64165 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
ARM: integrator: Fix early initialization
Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible which in turn calls of_syscon_register. This function allocates memory. Since the memory management code has not been initialized at that time, the call always fails. It either returns -ENOMEM or crashes as follows.
Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read [0000000c] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT Hardware name: ARM Integrator/CP (Device Tree) PC is at __kmalloc_cache_noprof+0xec/0x39c LR is at __kmalloc_cache_noprof+0x34/0x39c ... Call trace: __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310 of_syscon_register from device_node_get_regmap+0xa4/0xb0 device_node_get_regmap from intcp_init_early+0xc/0x40 intcp_init_early from start_kernel+0x60/0x688 start_kernel from 0x0
The crash is seen due to a dereferenced pointer which is not supposed to be NULL but is NULL if the memory management subsystem has not been initialized. The crash is not seen with all versions of gcc. Some versions such as gcc 9.x apparently do not dereference the pointer, presumably if tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x, and 13.x. Either case, if the crash is not seen, the call to syscon_regmap_lookup_by_compatible returns -ENOMEM, and sched_clock_register is never called.
Fix the problem by moving the early initialization code into the standard machine initialization code.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
This vulnerability represents a critical early boot initialization flaw in the ARM Integrator platform implementation within the Linux kernel. The issue occurs during the very early stages of system boot when the kernel attempts to initialize the interrupt controller through intcp_init_early function. The problem stems from a fundamental timing conflict where memory management subsystem components have not yet been initialized, yet the code attempts to allocate memory using functions like syscon_regmap_lookup_by_compatible that internally depend on kmalloc operations. This creates a classic circular dependency scenario where early boot code requires memory allocation capabilities that are not yet available, leading to either immediate kernel oops crashes or silent -ENOMEM failures.
The technical root cause manifests as a NULL pointer dereference at virtual address 0x0000000c, specifically in the __kmalloc_cache_noprof function when attempting to access memory management structures. The crash occurs because of_syscon_register function calls into memory allocation routines before the kernel's memory subsystem has been properly initialized, causing a NULL pointer dereference that results in an oops exception. This vulnerability is particularly interesting from a security perspective as it represents a potential denial-of-service vector that could prevent system boot entirely, and it demonstrates poor adherence to kernel initialization ordering principles.
The operational impact of this vulnerability extends beyond simple system crashes, as it affects the entire boot process and prevents proper scheduling clock registration through sched_clock_register. This means that systems using the ARM Integrator platform may fail to initialize properly, resulting in complete boot failures or unstable operation where critical timing functions are not available. The vulnerability is compiler-dependent, with newer gcc versions (10.x, 11.x, 13.x) being more likely to trigger the actual crash due to different optimization behaviors, while older versions like gcc 9.x might avoid the dereference through compiler optimizations.
The fix implemented addresses this issue by relocating the problematic early initialization code from the premature initialization path into the standard machine initialization code where memory management is guaranteed to be available. This follows established kernel development practices for early boot code organization and demonstrates proper adherence to the Linux kernel's initialization sequence requirements. The solution aligns with common security best practices for embedded systems and kernel development, ensuring that platform-specific initialization occurs in appropriate phases of system boot. This approach prevents the circular dependency between memory allocation and early device initialization while maintaining the intended functionality of the interrupt controller setup process. The vulnerability can be classified under CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and relates to ATT&CK technique T1490 (Inhibit System Recovery) through its potential to prevent system boot and recovery operations, making it a significant concern for embedded systems and server environments that rely on deterministic early boot behavior.