CVE-2024-27004 - Linux Kernel `clk_disable_unused` ABBA Deadlock Vulnerability Explained

CVE-2024-27004 is a recently patched vulnerability in the Linux kernel’s clock management subsystem. It was triggered by improper locking order in the interaction between the clock (clk) and runtime Power Management (PM) systems. This caused the kernel to deadlock during certain clock tree operations, notably while invoking clk_disable_unused on complex system setups.

Deadlocks like this can result in system hangs, requiring a hardware reset—a serious concern for user devices, embedded systems, servers, and more.

Below, we break down the bug, show relevant call traces, analyze the fixed code, and demonstrate how an attacker could potentially exploit this bug for denial-of-service (DoS) purposes. (Root/system privileges would typically be required.)

The global prepare_lock (protects clock tree operations)

- The device runtime PM resume/suspend mutex

Summary

- Thread A: Traverses the clock tree holding prepare_lock, and during that, triggers a runtime PM resume on a device.
- Thread B: Handles runtime PM resume for that device and, in its callback, tries to grab the same prepare_lock.

Result: Both threads are blocked waiting for each other—classic deadlock.

> “To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held.”
> – Commit Discussion

## Reproducing the Deadlock (Exploit/Reliable Trigger)

Note: This demonstration requires root/system access on a vulnerable kernel (such as 5.15.149).

Below is a conceptual script for triggering (DoS) via /sys

# As root, on a vulnerable kernel
echo 1 > /sys/kernel/debug/clk/disable_unused

# Alternatively (if supported, triggers at boot)
echo Y > /sys/kernel/debug/clk/force_disable_unused

# Now, the system may hang and kernel logs will show similar stack trace...

Monitor dmesg or journalctl -k for

INFO: task swapper/:1 blocked for more than 122 seconds.
Call trace:
  ...
  clk_disable_unused_subtree+...
  clk_pm_runtime_get+...
  ...
Another kworker thread similarly blocked...

*Your system may be unresponsive except for hardware reset.*

Example Stack Traces

From real-world bug reports (lkml 2024-01-30):

INFO: task swapper/:1 blocked for more than 122 seconds...
Call trace:
  clk_pm_runtime_get+x30/xb
  clk_disable_unused_subtree+x58/x208
  ...
INFO: task kworker/u16::9 blocked for more than 122 seconds...
Call trace:
  clk_prepare_lock+x7c/x9c
  clk_core_prepare_lock+x20/x44
  clk_prepare+x24/x30
  ...

The fix, merged into mainline and stable Linux (as of v5.15.150+), is

- Get the device's runtime PM before grabbing the global clk lock/prepare_lock during clk_disable_unused operations.

This avoids relocking after scheduling away.

Patch reference:
- clk: Get runtime PM before walking tree during disable_unused
- LKML Patch Discussion

Code Snippet (Relevant Fix Portion)

// Pseudocode similar to the real patch
int clk_pm_runtime_get(struct clk_core *core)
{
    int ret = ;
    if (core->dev) {
        // get before taking any global lock!
        ret = pm_runtime_get_sync(core->dev);
        if (ret < )
            pm_runtime_put_noidle(core->dev);
    }
    return ret;
}

Before the patch, this call could occur with prepare_lock held.

Who is Affected?

- All Linux distributions using an affected 5.15.x (or similar) kernel with devices utilizing runtime PM and complex clock trees

Attack Scenario

Denial-of-Service:
A local attacker with system privileges could reliably trigger a permanent kernel hang via the exposed sysfs's clk_disable_unused. In embedded scenarios, small fluctuations in attached devices could cause spontaneous hangs on boot, crashing production systems.

References

- Upstream Fix Commit
- Linux Kernel Mailing List Discussion
- Bug Report: LKML
- NVD Entry (pending/placeholder)

Conclusion

CVE-2024-27004 is a serious deadlock vulnerability in older Linux kernels’ clock and PM logic. It can be exploited for local denial-of-service due to a straightforward ABBA deadlock. The fix is simple but important for all affected setups.

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 11/04/2025 18:16:09 UTC