Published: June 2024
*Author: Kernel Security Researcher*


A recent vulnerability, CVE-2024-26975, was identified and subsequently patched in the Linux kernel’s Intel RAPL (Running Average Power Limit) driver, relating to the powercap subsystem. Let’s dive into what this bug was, how it can be triggered, the technical details, and how it was fixed.

What Is CVE-2024-26975?

This vulnerability is a NULL pointer dereference in the Intel RAPL driver for the Linux kernel. The bug is triggered when “probing” (initializing) the MMIO RAPL device on certain CPUs — notably, ones whose CPU IDs are *not* in the intel_rapl_common CPU model list.

How the Bug Occurs

- Commit 1488ac990ac8 allowed probing (attempting to initialize the driver) without a strict CPU model check.

Here is a simplified snippet showing the problematic code flow (pre-patch)

static int intel_rapl_mmio_probe(struct platform_device *pdev) {
    // ... code ...
    // Setup struct rapl_priv
    struct rapl_priv *priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);

    // Some code that may fail to set priv->rapl_defaults based on CPU
    priv->rapl_defaults = lookup_rapl_defaults(cpu_model);
    // On unsupported CPU, rapl_defaults may remain NULL

    // Later when registering:
    rapl_register_platform(priv);
    // Inside here, code such as:
    use_defaults(priv->rapl_defaults); // BOOM! NULL pointer
}

If lookup_rapl_defaults() does not find the CPU model, it returns NULL. The code then tries to dereference priv->rapl_defaults regardless, leading to a crash.

How Could This Be Exploited?

This is not directly a privilege escalation vulnerability since an attacker would need to load or trigger the RAPL code *on unsupported hardware* — a somewhat rare scenario outside of researchers or admins with custom hardware. However, any kernel NULL pointer dereference is potentially dangerous, as it could be a starting point for more serious escalation methods (especially under certain kernel configurations or attack surfaces).

Impact: Kernel crash (DoS - Denial of Service)

- Potential Exploit Vector: Unprivileged user triggers device probing on unsupported platforms (e.g., loading module or triggering probe via sysfs).

> Note: No obvious remote or unprivileged escalation path, but DoS is always undesirable in production systems.

How Was The Bug Fixed?

The patch (upstream commit diff) adds a NULL-pointer check before registering the RAPL framework:

// After patch - simplified:
if (!priv->rapl_defaults) {
    dev_err(&pdev->dev, "No RAPL defaults for this CPU model, aborting\n");
    return -ENODEV; // or appropriate error
}
rapl_register_platform(priv);

This check ensures the pointer is always valid. If not, driver initialization simply fails gracefully.

Proof-of-Concept Trigger (DoS Example)

If you have an unsupported Intel CPU and the RAPL MMIO driver (e.g., module intel_rapl_msr or intel_rapl_common) is probed, before the patch, the kernel will Oops (crash):

# Suppose intel_rapl_msr is built as a module
modprobe intel_rapl_msr
# On unsupported CPU platform, this could crash kernel

In dmesg (kernel logs), you might see something like

BUG: kernel NULL pointer dereference at 000000000000000
...
RIP: ...
intel_rapl_mmio_probe+x...

Official Reference:

- Kernel.org patch commit
- Debian Security Tracker
- Red Hat Security
- Mitigation: Block unsupported userspace access (do not load the intel_rapl_mmio module on unsupported platforms). Upgrade your kernel / track vendor advisories.

Summary Table

| CVE | Severity | Impact | Users Affected | Fixed In |
|-----------------|----------|---------------|-------------------------------|------------|
| CVE-2024-26975 | Low-DoS | Kernel Oops | Unsupported Intel CPUs, Linux | 6.9, backports |

Conclusion

While not a catastrophic kernel bug, CVE-2024-26975 is a classic example of how kernel drivers can be tripped up by subtle hardware differences. NULL pointer dereferences, even if “benign”, can turn into stability or security headaches. Always keep your systems updated and pay attention to these small but important kernel patches!

References

- Official Linux patch commit
- Debian Security Tracker Entry
- Red Hat CVE database

Timeline

Published on: 05/01/2024 06:15:14 UTC
Last modified on: 12/23/2024 14:02:46 UTC