CVE-2025-39895 in Linux
Sumário
de VulDB • 29/05/2026
Based on the kernel panic log provided, here is a detailed analysis of the crash, its root cause, and potential solutions.
### 1. Summary of the Crash * **Error Type:** Kernel Panic (`Attempted to kill init!`) * **Trigger:** An **Illegal Instruction** exception (Exit code `0x0000000b` corresponds to SIGILL). * **Failing Function:** `sched_numa_find_nth_cpu` * **Context:** The crash occurred during the initialization of the **ARMv8 PMU (Performance Monitoring Unit)** driver, specifically when probing the `armv8_cortex_a72_pmu` device. * **CPU Architecture:** ARM64 (AArch64), likely a Cortex-A72 based SoC.
---
### 2. Detailed Analysis
#### A. The Immediate Cause: Illegal Instruction The line: ``` [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
``` shows the machine code of the instruction that caused the fault. The instruction `f8767803` is highlighted in parentheses, indicating it was the one executed when the crash happened.
Decoding `f8767803` in AArch64: * This is a **Load Register (literal)** or similar instruction depending on the exact encoding, but more importantly, the fact that it triggered an **Illegal Instruction** exception means the CPU tried to execute an opcode it does not support or that is invalid in the current context. * In the context of `sched_numa_find_nth_cpu`, this often points to **compiler-generated code** or **kernel code** that uses an instruction not available on the specific CPU variant or is misaligned.
#### B. The Call Trace ``` sched_numa_find_nth_cpu+0x2a0/0x488 (P) smp_call_function_any+0xc8/0xd0 armv8_pmu_init+0x58/0x27c armv8_cortex_a72_pmu_init+0x20/0x2c arm_pmu_device_probe+0x1e4/0x5e8 ... ``` 1. The kernel is initializing the PMU driver for a Cortex-A72 core. 2. `armv8_pmu_init` calls `smp_call_function_any` to run code on another CPU. 3. The target function is `sched_numa_find_nth_cpu`, which is part of the scheduler's NUMA (Non-Uniform Memory Access) balancing logic. 4. **Why here?** The PMU driver likely needs to determine which CPU to use for performance monitoring events, and it queries the scheduler's NUMA topology.
#### C. Root Cause Hypotheses
##### Hypothesis 1: CPU Feature Mismatch / Compiler Bug (Most Likely) The instruction `f8767803` may be an **ARMv8.2-A** or **ARMv8.3-A** specific instruction (e.g., related to pointer authentication, memory tagging, or new atomic operations) that is being generated by the compiler but is **not supported** by the actual Cortex-A72 hardware (which is ARMv8.0-A).
* **Cortex-A72** supports up to **ARMv8.0-A**. * If the kernel was compiled with `-march=armv8.2-a` or similar, or if certain kernel configurations enable features that generate newer instructions, the CPU will fault when it encounters them. * The `(P)` in the call trace indicates the instruction was **Privileged** (executed in kernel mode), which is expected.
##### Hypothesis 2: Corrupted Kernel Image or Bootloader Issue * The instruction pointer might be pointing to corrupted memory. * If the kernel image was not properly loaded or if there is a memory corruption early in boot, the code at `sched_numa_find_nth_cpu+0x2a0` could be garbage.
##### Hypothesis 3: NUMA Topology Misconfiguration * The function `sched_numa_find_nth_cpu` is trying to find a CPU in a specific NUMA node. * If the device tree (DTB) provides incorrect NUMA information, or if the kernel's NUMA initialization is flawed, it might lead to invalid memory accesses or jumps. However, this usually results in a page fault, not an illegal instruction.
##### Hypothesis 4: SMP Call Function Issue * `smp_call_function_any` sends an IPI (Inter-Processor Interrupt) to another CPU to execute a function. * If the target CPU is not properly initialized, or if the function pointer passed is invalid, the target CPU might execute garbage code.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.