CVE-2024-27003 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree for clk_summary
Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path
because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/07/2026
The vulnerability identified as CVE-2024-27003 resides within the Linux kernel's clock management subsystem, specifically affecting the clk_summary debugfs interface. This issue represents a subtle but critical race condition that can lead to system deadlock conditions during concurrent device runtime power management operations. The flaw manifests when multiple threads attempt to access clock state information simultaneously, creating a scenario where one thread holds a runtime power management reference while another attempts to acquire the same resource, resulting in circular dependency and system hang.
The technical root cause stems from improper handling of runtime power management references within the clock summary debugging path. The kernel's clock framework previously relied on clk_pm_runtime_get() calls to ensure devices were powered up before accessing clock state information through debugfs. However, this approach created a dangerous dependency where the same device could be simultaneously resumed by multiple threads, leading to potential deadlocks. The vulnerability specifically occurs when a thread attempts to print clock state information while another thread is in the process of resuming the same device, such as when a display driver initializes and the screen turns on concurrently. This race condition violates fundamental concurrency principles and creates a scenario where the system cannot make forward progress.
This vulnerability directly relates to CWE-362, which describes a race condition in concurrent execution, and CWE-367, which addresses time-of-check to time-of-use flaws. The issue also maps to ATT&CK technique T1484.001, which involves privilege escalation through manipulation of system processes, as the deadlock condition can effectively disable system functionality and may be exploited to cause denial of service. The improper return value checking of clk_pm_runtime_get() creates additional complexity by introducing a potential RPM count underflow on error paths, which can corrupt the runtime power management subsystem's internal state and potentially lead to further instability.
The operational impact of this vulnerability extends beyond simple deadlock conditions to encompass broader system reliability concerns. When multiple threads attempt to access the clk_summary interface simultaneously, especially during device initialization sequences, the system may become unresponsive or require forced rebooting to recover. This is particularly problematic in embedded systems or mobile devices where runtime power management is critical for battery optimization and system responsiveness. The vulnerability affects any Linux kernel version that implements the affected clock management code and could be exploited by malicious actors to create persistent denial of service conditions or by legitimate system components that inadvertently trigger the race condition through concurrent access patterns.
Mitigation strategies for CVE-2024-27003 involve ensuring that runtime power management operations are properly synchronized before accessing debugfs interfaces. The fix implemented in the kernel removes the redundant clk_pm_runtime_{get,put}() calls from the clk_summary path, eliminating the race condition by ensuring that devices are already in the appropriate power state before attempting to access their clock information. System administrators should update to kernel versions containing the fix, which typically involves applying the specific commit that addresses the race condition. Additionally, monitoring tools should be implemented to detect unusual patterns of concurrent access to debugfs interfaces, as these may indicate potential exploitation attempts. The fix also includes proper error handling for runtime power management operations, preventing the RPM count underflow that could occur when error paths are taken. Organizations should also review their kernel configurations and ensure that debugfs interfaces are appropriately restricted in production environments where such race conditions could be exploited.