CVE-2024-26975 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
powercap: intel_rapl: Fix a NULL pointer dereference
A NULL pointer dereference is triggered when probing the MMIO RAPL driver on platforms with CPU ID not listed in intel_rapl_common CPU model list.
This is because the intel_rapl_common module still probes on such platforms even if 'defaults_msr' is not set after commit 1488ac990ac8 ("powercap: intel_rapl: Allow probing without CPUID match"). Thus the MMIO RAPL rp->priv->defaults is NULL when registering to RAPL framework.
Fix the problem by adding sanity check to ensure rp->priv->rapl_defaults is always valid.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/06/2026
The vulnerability described in CVE-2024-26975 represents a critical NULL pointer dereference issue within the Linux kernel's powercap framework, specifically affecting the intel_rapl driver implementation. This flaw manifests when the kernel attempts to probe the Memory-Mapped I/O (MMIO) RAPL driver on hardware platforms whose CPU identifiers do not appear in the intel_rapl_common CPU model compatibility list. The underlying problem stems from a regression introduced by commit 1488ac990ac8 which relaxed the CPUID matching requirements for probing, allowing the driver to initialize on unsupported platforms without proper validation of the required hardware configuration parameters. This change created a scenario where the driver initialization process continues despite missing essential configuration data, leading to a fundamental system instability.
The technical execution of this vulnerability occurs during the driver probing phase when the kernel attempts to register the RAPL framework components without ensuring proper initialization of the required data structures. Specifically, the rp->priv->defaults pointer remains uninitialized or NULL when the driver attempts to register with the RAPL framework, causing a NULL pointer dereference that results in a kernel oops or system crash. This issue directly maps to CWE-476 which identifies NULL pointer dereference vulnerabilities in software systems, particularly those involving hardware abstraction layers where improper initialization sequences can lead to system-wide failures. The flaw demonstrates a classic case of inadequate input validation and resource management within kernel space drivers, where the assumption of proper hardware compatibility is violated without proper defensive programming measures.
The operational impact of this vulnerability extends beyond simple system crashes to potentially compromise system availability and stability in production environments. When triggered on affected platforms, the NULL pointer dereference can cause immediate system panics or kernel oops messages that force system reboots, disrupting ongoing operations and potentially leading to data loss or service interruptions. The vulnerability affects systems running Linux kernels that have incorporated the problematic commit, making it particularly concerning for enterprise environments where system uptime and reliability are critical. Attackers could potentially exploit this vulnerability to cause denial of service conditions, though the attack surface is limited to systems with unsupported CPU configurations where the driver initialization path is exercised.
Mitigation strategies for this vulnerability require immediate kernel updates to address the specific NULL pointer dereference issue in the intel_rapl driver implementation. System administrators should prioritize applying the relevant kernel patches that include the sanity check fix ensuring that rp->priv->rapl_defaults is properly validated before driver registration. The fix implements a defensive programming approach that prevents the driver from proceeding with registration when essential hardware configuration data is unavailable, thereby preventing the kernel crash scenario. Organizations should also conduct inventory assessments to identify systems running affected kernel versions and verify their hardware compatibility with the intel_rapl driver. Additionally, monitoring systems should be configured to detect kernel oops messages or system panics that might indicate exploitation attempts, as this vulnerability operates at the kernel level where traditional application-based security measures are ineffective. The solution aligns with ATT&CK technique T1499.001 which involves system network configuration modification, specifically addressing kernel-level integrity violations through proper validation mechanisms.