CVE-2024-27004 is a vulnerability identified in the Linux kernel related to the clock (clk) subsystem's runtime power management (PM) implementation. The issue arises from a classic ABBA deadlock scenario involving two kernel threads interacting with the clk tree and device runtime PM operations. Specifically, one thread walks the clk tree and calls clk_pm_runtime_get() to power on devices required to read clock hardware status, holding the clk prepare_lock while attempting to runtime PM resume a device. This thread schedules away waiting for the device to finish resuming. Concurrently, a second thread is performing a runtime PM resume on the same device, and during its resume callback, it calls clk_prepare(), attempting to acquire the same prepare_lock held by the first thread. This circular dependency results in a deadlock, causing kernel tasks to hang for extended periods (over 122 seconds as observed). The deadlock occurs because the runtime PM resume or suspend operations are performed while holding the clk prepare_lock, which is not designed to be released and reacquired mid-operation without risking inconsistency in the clk tree topology. The complexity of the clk tree and the global nature of the prepare_lock make it difficult to restructure the locking to avoid this deadlock without risking other issues. The vulnerability manifests as system hangs or blocked kernel tasks, impacting system availability. Although the full fix is complex, the immediate resolution involves avoiding runtime PM resume or suspend calls while holding the prepare_lock, reducing the likelihood of this deadlock. This vulnerability affects Linux kernel versions around 5.15.149 and possibly others with similar clk subsystem implementations. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet.

For European organizations relying on Linux-based systems, especially those using kernel versions affected by this vulnerability, the primary impact is on system availability and stability. Systems may experience hangs or blocked kernel tasks, leading to degraded performance or complete system unresponsiveness. This can disrupt critical services, especially in environments where Linux is used for servers, embedded devices, or infrastructure components. Industries such as telecommunications, manufacturing, finance, and public sector entities that deploy Linux in their operational technology or IT infrastructure could face operational interruptions. The deadlock could affect devices that rely heavily on runtime power management, including mobile devices, IoT gateways, and edge computing platforms. While confidentiality and integrity are not directly impacted by this vulnerability, the availability impact can lead to denial of service conditions, potentially causing downtime and associated financial and reputational damage. Given the complexity of the issue, recovery may require system reboots or kernel updates, which could be disruptive in production environments.

To mitigate CVE-2024-27004, European organizations should: 1) Prioritize updating Linux kernels to versions where this vulnerability is patched or mitigated, as the Linux kernel community has addressed the deadlock by modifying runtime PM calls to avoid holding the clk prepare_lock during resume/suspend operations. 2) For systems where immediate kernel updates are not feasible, consider applying vendor-provided backported patches or workarounds that address the deadlock condition. 3) Monitor system logs for hung task warnings related to clk and runtime PM operations to detect potential deadlock occurrences early. 4) In environments with custom kernel builds or embedded Linux devices, coordinate with vendors or internal development teams to integrate the fix or implement equivalent locking changes. 5) Implement robust system monitoring and automated recovery mechanisms to detect and remediate hung tasks or system unresponsiveness caused by this deadlock. 6) Test kernel updates and patches in staging environments to ensure stability before deployment in production, as changes to power management and clock subsystems can have broad effects. 7) Review and optimize device driver interactions with the clk subsystem to minimize complex locking scenarios that could exacerbate deadlocks. These steps go beyond generic advice by focusing on kernel version management, targeted monitoring, and vendor coordination specific to this vulnerability.