CVE-2024-53230

What it actually does

Null pointer dereference in cppc_get_cpu_cost() when cpufreq_cpu_get_raw() returns NULL for a CPU outside policy->cpus mask, resulting in kernel memory corruption or crash.

Why it matters to the business

Potential system instability or denial of service on affected Linux systems; low exploitability reduces immediate operational risk but still requires patching to maintain kernel reliability.

How an attack unfolds

An attacker with local access triggers cpufreq operations that call cppc_get_cpu_cost() on a CPU not present in the active policy mask, causing the kernel to dereference a null pointer and potentially crash or corrupt memory.

How to fix it

Update the Linux kernel to a version containing commit 1975b481f644f8f841d9c188e3c214fce187f18b or later that adds the NULL check in cppc_get_cpu_cost().

How to confirm the fix worked

Verify the kernel source contains the NULL pointer check before calling cppc_get_cpu_cost() and confirm the system boots without cpufreq-related crashes after upgrade.

Typical attack path

1. Obtain local code execution on target Linux system
2. Manipulate CPU frequency or policy state to invoke cppc_get_cpu_cost() for a CPU outside policy->cpus
3. Trigger null pointer dereference leading to kernel panic or memory corruption

How to detect it

Review kernel logs for oops or panic messages referencing cpufreq or cppc_get_cpu_cost(); examine crash dumps for null pointer dereference patterns in cpufreq paths.

What your security team should do

• Prioritize kernel updates on all production Linux systems using CPPC cpufreq
• Monitor for kernel oops or panics involving cpufreq after deployment
• Apply the fix within standard patch cycles given low EPSS and no KEV listing