In early 2024, security researchers from Linux Verification Center (LVC) uncovered a vulnerability in the Linux kernel’s Broadcom STB AVS CPU frequency driver (brcmstb-avs-cpufreq). This vulnerability, identified as CVE-2024-27051, could result in a system crash due to a missing NULL pointer check. Let’s dig into what this means, see the code, and learn how it was fixed—step by step, in simple terms.

What Is CVE-2024-27051?

CVE-2024-27051 is a bug in the Linux kernel, specifically in the “cpufreq” subsystem. The flaw is in how the brcmstb-avs-cpufreq driver calls cpufreq_cpu_get without checking if it returned NULL. If this happened, later code tries to use this null pointer, causing a kernel panic (crash).

A bug like this doesn’t lead to a direct security exploit (like root access), but it could allow a local attacker (or just bad luck) to crash the machine. In containerized or production environments, that’s a big problem.

How the Bug Happened

Let’s look at an example that demonstrates the problem. In the code, cpufreq_cpu_get(cpu) is used to get CPU frequency policy for a CPU. According to the kernel API, this can return NULL if the policy doesn’t exist for the given CPU.

Original buggy code (simplified)

struct cpufreq_policy *policy;

policy = cpufreq_cpu_get(cpu);
// ... no check here ...
freq = policy->cur; // CRASH if policy is NULL!
cpufreq_cpu_put(policy);

If cpufreq_cpu_get(cpu) returns NULL, any access like policy->cur will dereference a null pointer. In the Linux kernel, this causes an “Oops” (kernel crash).

The Fix

The fix is simple: check if policy is NULL, and if so, return or handle the error gracefully. Here’s how the fixed code looks:

struct cpufreq_policy *policy;

policy = cpufreq_cpu_get(cpu);
if (!policy)
    return ;

freq = policy->cur;
cpufreq_cpu_put(policy);

Now, if cpufreq_cpu_get(cpu) returns NULL, the function will just return without causing any crash.

How Was the Vulnerability Found?

The bug was automatically detected by the SVACE static analysis tool maintained by Linux Verification Center. Static analyzers are great at spotting missed checks and possible null dereferences like this.

Kernel versions before the patch was applied.

If you’re using a mainline or distribution kernel after late February/March 2024, you’re likely safe. But embedded devices using vendor-patched or older kernels may still be exposed.

How to Fix

Update to a Linux kernel version including the patch for CVE-2024-27051. If you build your own kernels (for embedded devices, for instance), you can manually apply the patch as shown above.

Exploitation Details

While this bug isn’t easily exploitable for privilege escalation or arbitrary code execution, crashing the system can be used as a denial-of-service (DoS) attack. Anyone with the ability to trigger frequency scaling on an affected CPU could in theory cause a kernel panic by causing cpufreq_cpu_get to return NULL. For example, you could write a simple user-space program that tries to change or query CPU frequencies on the affected hardware.

Proof-of-concept (illustrative, would require root and affected hardware)

# On an affected system, repeated calls that trigger cpufreq_ops can hit the null deref:
while true; do
    cpufreq-info -c 
done

This is only a rough example. Specific exploitation depends on hardware and the kernel’s state.

Official Patch:

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

CVE Record:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27051
- Discovery by LVC: https://linuxtesting.org/
- Kernel cpufreq API docs: https://www.kernel.org/doc/html/latest/cpu-freq/index.html

Summary

CVE-2024-27051 is a classic example of how a missed NULL check in kernel code can cause big reliability problems. Thanks to static analysis and open development, this bug is fixed and documented. Always keep your systems updated and audit kernel code for these simple yet critical mistakes.

Timeline

Published on: 05/01/2024 13:15:50 UTC
Last modified on: 12/23/2024 19:11:23 UTC