CVE-2025-39895 in Linux
Riassunto
di VulDB • 02/07/2026
Based on the kernel panic log provided, here is a detailed analysis of the crash and potential solutions.
### **Summary** The system crashed during early boot while initializing the **ARMv8 Performance Monitoring Unit (PMU)** driver (`armv8_pmu`). The crash occurred in `sched_numa_find_nth_cpu`, which was called by `smp_call_function_any`. This suggests a failure when trying to schedule work on another CPU, likely due to an invalid memory access or hardware/driver incompatibility.
---
### **Key Log Analysis**
1. **Crash Location**: ```text Call trace: sched_numa_find_nth_cpu+0x2a0/0x488 (P) smp_call_function_any+0xc8/0xd0 armv8_pmu_init+0x58/0x27c ... ``` - The kernel was trying to initialize the PMU (`armv8_pmu_init`). - It called `smp_call_function_any` to run a function on another CPU. - Inside that context, it crashed in `sched_numa_find_nth_cpu`.
2. **Register State**: ```text x0 : ffffff8000407b68 x1 : ffffffc0846eb000 ... Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) ``` - The `Code` line shows the instruction that caused the fault. `(f8767803)` is likely a load/store instruction (`ldp`, `ldr`, etc.) accessing memory at an invalid address or with incorrect permissions.
3. **Panic Message**: ```text Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ``` - The kernel panicked because the `init` process (PID 1) died with signal code `0xb` (SIGSEGV, segmentation fault). This is a consequence of the earlier crash in the scheduler/PMU initialization.
---
### **Root Cause Hypotheses**
#### **1. PMU Driver Bug or Incompatibility** - The ARMv8 PMU driver (`arm_pmu`) may have a bug when interacting with your specific SoC (System on Chip). - Some older kernels had issues with NUMA-aware CPU scheduling during early boot, especially if the device tree incorrectly describes CPU topology.
#### **2. Device Tree (DTS) Issues** - The `sched_numa_find_nth_cpu` function relies on correct NUMA node information from the device tree. - If your DTS file has incorrect or missing `cpu-map`, `numa-node-id`, or PMU-related properties, this can cause invalid memory accesses during CPU hotplug/initialization.
#### **3. Hardware Erratum** - Some ARM Cortex-A72 (mentioned in the trace: `armv8_cortex_a72_pmu_init`) SoCs have known hardware errata that require kernel workarounds. If your kernel is too old or lacks specific patches, it may crash when accessing PMU registers.
#### **4. Memory Corruption** - Although less likely given the clean trace start, early memory corruption could cause invalid pointers in `sched_numa_find_nth_cpu`.
---
### **Recommended Solutions**
#### **Step 1: Disable PMU Driver (Quick Workaround)** If you don’t need performance monitoring during boot, disable the driver to bypass the crash. Add this to your kernel command line (`bootargs`): ```bash arm_pmu.disable=1 ``` Or in U-Boot environment: ```bash setenv bootargs "console=ttyS0,... arm_pmu.disable=1" saveenv ```
#### **Step 2: Update Kernel** - Ensure you are using a recent stable kernel (e.g., Linux 5.10+ or mainline). Many PMU and NUMA scheduling bugs were fixed in later kernels. - Check for specific patches related to `arm_pmu` and `sched_numa_find_nth_cpu`.
#### **Step 3: Verify Device Tree** - Review your device tree source (DTS) file, especially the `cpus` node and PMU nodes (`pmu@...`). - Ensure that: - All CPUs are correctly defined. - NUMA topology is either correct or disabled if not needed (`numa=off` in bootargs). - There are no duplicate or conflicting
VulDB is the best source for vulnerability data and more expert information about this specific topic.