In early 2024, a serious deadlock vulnerability affecting the MediaTek clock controllers in the Linux kernel was discovered and patched, now known as CVE-2024-27002. This post breaks down how this bug happened, how it could be exploited, and how the Linux kernel community fixed it. If you deal with embedded systems, Chromebooks, or MediaTek SoCs, this is important reading.

Summary

CVE ID: CVE-2024-27002
Affected Component: Linux kernel — MediaTek clk (clock) driver
Vulnerable Devices: Any Linux system using MediaTek SoCs and their clk drivers, including popular Chromebooks
Exploit Type: Kernel-level Deadlock (Denial of Service)
Severity: Medium (DoS, not privilege escalation)

What Happened? (Root Cause Analysis)

During the initialization (probing) of MediaTek’s clock controllers, a deadlock could occur due to a circular dependency between runtime power management (PM) and generic power domains (genpd) locking. This was most observable on mt8183-mfgcfg (used in MediaTek MT8183 SoCs), but it potentially affected all MediaTek clock controller drivers.

CPU Path (genpd first, then clk)

genpd_lock
  -> generic_pm_domain::power_off()
      -> clk_unprepare()
          -> clk_prepare_lock()

CPU1 Path (clk first, then genpd)

clk_prepare_lock
  -> clk_pm_runtime_get()
      -> genpd_lock()

Result:
If CPU holds genpd_lock and is waiting for clk_prepare_lock, while CPU1 holds clk_prepare_lock and waits for genpd_lock, both threads hang forever — a classic deadlock.

Threat Scenario: How Could This Be Abused?

Effect:
An attacker with the ability to trigger device probing — such as plugging in peripherals, manipulating driver sysfs attributes, or forcing device re-initialization — could intentionally "freeze" device drivers, potentially hanging the entire system (Denial of Service).

While this is not a remote code execution or privilege escalation bug, on single-board systems or Chromebooks, it could be used to crash a system, making it unavailable until rebooted.

The Fix (Patch Overview)

To break the deadlock, maintainers modified the MediaTek clk drivers to always do a runtime PM "get" call in the probe function — _before_ anything that might indirectly grab genpd locks. This way, the lock acquisition order is always the same, so circular waits cannot happen.

Key insight:
> Instead of patching just one SoC (mt8183-mfgcfg), the fix applies to all MediaTek clock controllers, ensuring no regressions across SoCs.

Before (problematic code)

static int mtk_clk_probe(struct platform_device *pdev)
{
    // ... stuff omitted ...
    clk_register(...); // may acquire locks in the wrong order!
    // ...
}

After (patched code)

static int mtk_clk_probe(struct platform_device *pdev)
{
    struct device *dev = &pdev->dev;

    pm_runtime_get_sync(dev); // <--- Always get runtime PM early!

    clk_register(...); // Now lock ordering is safe
    // ...

    pm_runtime_put(dev);
    return ;
}

This ensures the power domain state is stable, so clk_register() will not try to acquire the genpd lock in the wrong context.

Upstream Linux commit (mainline fix):

clk: mediatek: Do a runtime PM get on controllers during probe

CVE Entry:

CVE-2024-27002 at cve.org

Chromebook Report:

MediaTek Chromebook bug report

MediaTek MT8192 Chromebooks

If you use a kernel with these SoCs, update ASAP to prevent unexpected lockups.

Note: This is not remote code execution, but illustrates a possible denial-of-service

# As root, force reprobe of a device (simplified example)
echo 1 > /sys/bus/platform/devices/mt8183-mfgcfg/unbind
echo 1 > /sys/bus/platform/devices/mt8183-mfgcfg/bind

# Or cause device power domains to toggle
echo auto > /sys/bus/platform/devices/mt8183-mfgcfg/power/control

If triggers are timed on different cores, you could eventually cause one thread to hold genpd_lock and another to hold clk_prepare_lock, deadlocking the kernel.

Mitigation and Final Recommendations

- Update your kernel. Make sure your MediaTek device is running a kernel with the patch referenced above.
- Restrict access to /sys interfaces. Only trusted users should be able to rebind drivers or manipulate power domains.
- Monitor for system hangs. If your system becomes unresponsive after device probe, check if you’re running a vulnerable kernel.

Conclusion

CVE-2024-27002 is a sophisticated deadlock bug specific to the interaction of Linux's clock framework and MediaTek's power domains. While not a privilege escalation vector, it can halt important devices or systems. Maintaining kernel hygiene by updating is your best defense!

> Stay tuned and always patch early — especially if you’re in the embedded or Chromebook world!


For more kernel CVE explanations and fix walkthroughs, [subscribe to our blog](#) or follow us on [GitHub](#)!
Stay secure 👊


References:
- https://www.cve.org/CVERecord?id=CVE-2024-27002
- Linux Kernel Patch Commit
- Chromium Bug Report


*This explanation is exclusive — written in plain English for everyone who deals with Linux driver fuzz.*

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 12/23/2024 19:51:06 UTC