CVE-2026-64165

What it actually does

This Linux kernel flaw affects the ARM Integrator/CP platform initialization path. During very early boot, intcp_init_early() calls syscon_regmap_lookup_by_compatible(), which can allocate memory through of_syscon_register() before the kernel memory-management subsystem is ready. Depending on compiler version and build options, this can either trigger a NULL pointer dereference in the allocator path and crash the kernel during boot, or return -ENOMEM and skip sched_clock_register(), leaving platform timekeeping initialization incomplete. The practical technical impact is a local/boot-time denial of service or failed initialization on affected ARM Integrator systems rather than a remote code-execution primitive.

Why it matters to the business

Systems built for the affected ARM Integrator/CP kernel configuration may fail to boot or may boot with incomplete early platform initialization after deploying a vulnerable kernel. In operational terms, this can cause outages for embedded, lab, test, or legacy ARM environments that rely on this platform support. The issue is not currently listed in CISA KEV, has no known ransomware association, has very low EPSS, and has no reported exploit maturity, so urgency is primarily driven by whether an organization runs this specific ARM platform or ships kernels that support it.

How an attack unfolds

This vulnerability is not typically exploited by a remote attacker over the network. The failure occurs during kernel startup on affected ARM Integrator/CP systems when the vulnerable initialization sequence is present. An attacker would generally need the ability to cause an affected kernel build to be booted on matching hardware or emulation, such as through supply-chain manipulation, malicious downgrade, unauthorized kernel replacement, or abuse of an update mechanism. Once that kernel boots, the early initialization path attempts memory allocation before memory management is initialized; the result is a boot-time kernel crash or failed clock registration, producing a denial of service.

How to fix it

Apply a Linux kernel version or vendor kernel update that includes the fix moving the ARM Integrator initialization from the early initialization phase into the standard machine initialization phase. Because no exact fixed package versions were provided, use the fixed kernel releases or backported patches published by the relevant Linux distribution, board-support-package vendor, or kernel supplier. If immediate patching is not possible, avoid deploying affected kernel builds to ARM Integrator/CP systems, prevent untrusted kernel or firmware updates, and use a previously known-good kernel that does not contain the vulnerable initialization change. Organizations that do not build or run Linux kernels for ARM Integrator/CP are unlikely to be exposed.

How to confirm the fix worked

Confirm exposure by reviewing kernel configuration, platform support, and boot target: systems must be using an affected Linux kernel build for ARM Integrator/CP or related Integrator device-tree platform code. Validate remediation by boot-testing the patched kernel on affected hardware or emulation and confirming that early boot completes without NULL pointer dereference, allocator failures, or missing sched_clock registration symptoms. Review boot logs for absence of messages such as 'Unable to handle kernel NULL pointer dereference', '__kmalloc_cache_noprof', 'of_syscon_register', and 'intcp_init_early'. Also confirm that the running kernel version contains the upstream or vendor backport for the ARM Integrator early initialization fix.

Typical attack path

1. Gain the ability to influence the kernel image, boot configuration, firmware update, or system image used on an affected ARM Integrator/CP platform.
2. Ensure the target boots a vulnerable Linux kernel containing the flawed ARM Integrator early initialization sequence.
3. During start_kernel(), trigger the ARM Integrator early init path that calls intcp_init_early().
4. The vulnerable path calls syscon_regmap_lookup_by_compatible() and of_syscon_register(), which attempts allocation before memory management is initialized.
5. The kernel either dereferences a NULL pointer and panics during boot, or receives -ENOMEM and skips sched_clock_register(), resulting in denial of service or incomplete platform initialization.

How to detect it

Look for evidence of failed or abnormal kernel boots on ARM Integrator/CP systems. Primary sources are serial console captures, bootloader logs, kernel ring buffers, crash logs, hypervisor/emulator console output, and system management logs that preserve failed boot output. Indicators include a kernel Oops or panic during start_kernel(), NULL pointer dereference near address 0000000c, allocator stack frames such as __kmalloc_cache_noprof, and call traces involving of_syscon_register, device_node_get_regmap, and intcp_init_early. Because this issue manifests during early boot, normal host-based logging may not persist; collect serial console output or out-of-band logs. To investigate potential malicious involvement, correlate boot failures with recent kernel image changes, firmware or bootloader updates, package downgrades, unsigned image attempts, unexpected changes to /boot contents, or unauthorized CI/build pipeline changes. No public threat actors or active exploitation are currently associated with this vulnerability.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000c
• Internal error: Oops: 5 [#1] ARM
• PC is at __kmalloc_cache_noprof
• __kmalloc_cache_noprof from of_syscon_register
• of_syscon_register from device_node_get_regmap
• device_node_get_regmap from intcp_init_early
• intcp_init_early from start_kernel
• Hardware name: ARM Integrator/CP (Device Tree)
• sched_clock_register is never called
• syscon_regmap_lookup_by_compatible returns -ENOMEM

What your security team should do

• Prioritize inventory first: determine whether any production, embedded, lab, CI, or emulator environments run Linux kernels for ARM Integrator/CP.
• If affected systems exist, obtain and test the vendor or upstream kernel update containing the ARM Integrator initialization fix.
• Prevent unauthorized kernel, firmware, and bootloader changes, since practical abuse requires influencing what kernel is booted.
• Add boot-failure monitoring for affected ARM platforms, especially after kernel upgrades or board-support-package changes.
• Do not treat this as an internet-facing remote exploitation emergency unless local update or boot-chain compromise is plausible in the environment.
• For product teams shipping ARM kernel images, backport the fix and add boot regression tests that exercise Integrator/CP initialization.