CVE-2025-38610

What it actually does

NULL pointer dereference in get_pd_power_uw() when em_cpu_get() returns NULL after get_cpu_device() fails for an unavailable CPU, causing em_span_cpus() to crash.

Why it matters to the business

Unexpected system crashes and loss of availability on Linux deployments; widespread kernel presence amplifies operational disruption risk even without confirmed ransomware use.

How an attack unfolds

Local attacker forces a CPU into an impossible runtime state, causing get_cpu_device() and em_cpu_get() to return NULL; subsequent call to get_pd_power_uw() dereferences the NULL pointer and crashes the kernel. Observed in container-optimized OS privilege-escalation chains alongside related CVEs.

How to fix it

Apply kernel patch 27914f2b795e2b58e9506f281dcdd98fef09d3c2 or later; update affected Chainguard packages to 0.53.0-r0.

How to confirm the fix worked

Confirm running kernel contains commit 27914f2b795e2b58e9506f281dcdd98fef09d3c2; verify Chainguard package versions are 0.53.0-r0 or newer; attempt CPU offline operations while monitoring for panics.

Typical attack path

1. Obtain local execution on vulnerable Linux kernel
2. Trigger CPU offline or impossible state via scheduler or hotplug interfaces
3. Invoke powercap dtpm_cpu path that calls get_pd_power_uw()
4. Trigger NULL dereference and kernel panic

How to detect it

Search kernel logs and dmesg for oops/panic messages referencing get_pd_power_uw, em_cpu_get, or em_span_cpus NULL dereference; correlate with container runtime CPU hotplug events.

What your security team should do

• Immediately upgrade Linux kernels to the fixed commit
• Update listed Chainguard OpenJDK packages to 0.53.0-r0
• Harden container runtimes against CPU state manipulation used in related escalation chains
• Increase monitoring for kernel oops involving powercap and em_cpu_get