Cloudanix VulnDB

CVE-2025-39752

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Sep 11, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A startup timing problem on certain Rockchip chips can make the computer freeze before it finishes booting when multiple processor cores are present.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition during ARM Rockchip SMP initialization allows secondary CPUs to execute trampoline code written to SRAM before the kernel expects it, resulting in a hang.

Why it matters to the business

Systems using affected Rockchip SoCs may fail to boot reliably on multi-core hardware, causing downtime and reduced availability for dependent workloads.

How an attack unfolds

An attacker with local access can trigger or observe the SMP initialization sequence during boot; the race allows premature execution of uninitialized trampoline code leading to kernel hang.

How to fix it

Apply the fix from commit 3c6bf7a324b8995b9c7d790c8d2abf0668f51551 or update to a kernel containing this change; ensure SRAM initialization occurs only after secondary CPUs are powered down.

How to confirm the fix worked

Boot the patched kernel on affected Rockchip hardware and confirm absence of hangs during SMP bring-up; verify the rockchip_smp_prepare_cpus log sequence completes without error.

Typical attack path

  1. Boot kernel on multi-core Rockchip SoC with secondary CPUs powered on
  2. Main CPU begins writing trampoline code to SRAM
  3. Secondary CPU executes trampoline prematurely
  4. Kernel enters unexpected state and hangs

How to detect it

Inspect early kernel boot logs for rockchip_smp_prepare_cpus messages followed by hangs; search for repeated CPU thread initialization entries that precede system freeze on unpatched kernels.

  • rockchip_smp_prepare_cpus: ncores
  • CPU0: thread -1, cpu 0, socket 0, mpidr 80000000

What your security team should do

  • Prioritize patching kernels on all Rockchip-based devices due to boot-time availability impact
  • Test the fixed commit in staging environments before production rollout
  • Monitor boot logs for SMP initialization anomalies on unpatched systems

The record

In the Linux kernel, the following vulnerability has been resolved: ARM: rockchip: fix kernel hang during smp initialization In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 6.12.43-1
Debian:14 linux 0 6.16.3-1
Linux Kernel 3.19.0 5.4.297

Related vulnerabilities