CVE-2024-27003

What it actually does

Race condition in clk_summary debugfs handler allows concurrent runtime PM operations on the same device, leading to deadlock or RPM reference count underflow when return value of clk_pm_runtime_get is not checked.

Why it matters to the business

Kernel threads can deadlock during device resume sequences triggered by display or other power events, causing system hangs, degraded responsiveness, or crashes on Linux-based devices including embedded and mobile platforms with high prevalence of downstream kernel dependents.

How an attack unfolds

An attacker with access to trigger debugfs clk_summary output (via local process or kernel debug interface) races with normal device runtime resume paths; failure to ensure prior runtime resume creates circular wait, while unchecked get calls produce underflow; threat actor references to Android kernel RCE campaigns highlight potential for local privilege escalation chains when combined with other bugs.

How to fix it

Update to Linux kernel commit 83ada89e4a86e2b28ea2b5113c76d6dc7560a4d0 or later stable trees that include the runtime PM ordering fix before clk_summary walk and removal of unchecked clk_pm_runtime_get calls.

How to confirm the fix worked

Confirm kernel source contains the referenced commit; test by exercising clk_summary debugfs while inducing runtime resume events and verify no deadlock or negative RPM counts occur.

Typical attack path

1. Obtain local execution or debugfs access on target kernel
2. Trigger concurrent device resume (e.g., screen on event) while reading clk_summary
3. Exploit resulting deadlock or RPM underflow to disrupt kernel threads
4. Chain with additional vulnerabilities for privilege escalation or denial of service

How to detect it

Review kernel logs for hung_task or deadlock warnings involving clk_summary or pm_runtime; inspect debugfs access patterns and device resume sequences around display or power management drivers; correlate with threat actor mentions of Android kernel exploitation campaigns.

What your security team should do

• Prioritize kernel upgrades to the fixed commit on all affected stable branches within 30 days given ecosystem prevalence
• Restrict debugfs access via mount options or SELinux policies until patched
• Monitor for kernel oops or hung task reports involving clk or pm_runtime
• Apply compensating controls such as disabling unnecessary clk debug output in production kernels