The Linux kernel, the backbone of many servers, desktops, and embedded systems around the world, takes system clocks seriously. These clocks are managed by the Common Clock Framework (CCF), critical for controlling efficient device access and power management.

In early 2024, a security issue was discovered and fixed, tracked as CVE-2024-27003. This bug could cause serious system hangs (deadlocks) when inspecting clock status using the kernel’s debug interface, especially on systems actively resuming devices at runtime.

What Was CVE-2024-27003?

In short:
When accessing debug information about hardware clocks via /sys/kernel/debug/clk/clk_summary, the kernel could deadlock if devices were being woken up ("runtime resumed") in parallel. This happened because the kernel tried to get power management references too late, and sometimes without error checking.

Technical Context

The Linux clock subsystem gathers the state of all system clocks for debugging. To print this summary correctly, all devices involved need to be "powered on" or "resumed." If the kernel tries to resume a device while another thread (like a display driver) is doing the same, this can cause both threads to wait for each other — a deadlock.

Previously, the code only tried to increment ("get") the runtime power management (PM) count inside the recursive walking of the clocks, not before entering it. Worse, return values from these calls weren’t always checked. If an error happened (such as failing to get a device), the PM counts could get messed up, risking resource leaks or underflows.

Exploit Details

This bug is not a classic security exploit leading to privilege escalation, but a stability issue which could lead to system denial-of-service (DoS) situations.

How Could It Be Triggered?

- A user or developer runs cat /sys/kernel/debug/clk/clk_summary.
- At the same time, a device driver (like for a display) is activating its device — for instance, when a screen turns on.
- Because the kernel tries to resume devices during clk_summary generation, and because the power management calls are not properly checked, the process can stall.

If both processes are waiting for each other’s lock or resource, the entire kernel could freeze.

Who’s at risk?
Any Linux user on an affected kernel version who uses debugfs to read clock summaries, especially on systems with active runtime power management and multiple driver activities.

The Fix for CVE-2024-27003

The fix makes sure that all necessary devices are resumed *before* beginning the debug information walk. This avoids the classic “thread A waits for thread B, while thread B waits for thread A” problem.

Additionally

- Calls to clk_pm_runtime_get() and clk_pm_runtime_put() are removed from the walk, since all devices are already resumed.
- The bug where clk_pm_runtime_get() errors led to PM count underflows is fixed (since the call is gone).

Before (buggy)

static void clk_summary_show(...)
{
    ...
    clk_pm_runtime_get(dev);  // Get PM on each device individually (CAN FAIL, NOT CHECKED)
    walk_clk_tree();          // Recurse into clock devices
    clk_pm_runtime_put(dev);  // Put PM reference
    ...
}

If clk_pm_runtime_get() fails, nothing checks the return. Continued execution can underflow the PM count.

After (fixed)

static void clk_summary_show(...)
{
    resume_all_devices();      // *Before* walking tree, resume all needed
    walk_clk_tree();           // Safe to walk, no risk of mid-walk resume deadlocks
    // No need to get/put PM in the walk anymore
}

How to Know If You’re Impacted

Affected Kernels:

Check with

uname -r
dmesg | grep clk

And see if you have /sys/kernel/debug/clk/clk_summary.

How to Patch

- Upgrade your kernel to a release that includes the fixing commit.

References

- CVE Record: CVE-2024-27003
- Upstream Fix Commit (kernel.org)
- Linux Kernel Documentation: Common Clock Framework
- Linux PM Runtime Guide

Conclusion

CVE-2024-27003 may not let attackers take over your system, but it can freeze production devices — especially those needing high uptime and reliability. All Linux kernel users should patch, particularly those working with debug tools or developing device drivers.

Make sure your kernels are up to date. If you find yourself using the clock debug interface on embedded or desktop Linux, don’t skip this fix!


*(This article is exclusive to this knowledge base. Please feel free to comment or reach out if you have kernel questions or want to know more about Linux debugging!)*

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 12/23/2024 20:39:58 UTC