In the Linux kernel, the function devm_clk_get_optional_enabled_with_rate() registered its cleanup action before successfully preparing and enabling the clock. When setting the clock rate fails, the cleanup routine mistakenly attempts to disable and unprepare a clock that was never enabled, which can corrupt the clock state and trigger a kernel crash. This flaw represents an improper release of resources and can lead to system instability or denial of service. The vulnerability is specific to the clock driver subsystem and involves mismatched resource management. Attackers could exploit this by provoking resource failures through a driver or module that calls the affected function, potentially resulting in a crash. The flaw falls under the category of improper resource release and can affect any Linux kernel version that contains the bug before the provided fix was merged.

The issue resides in the Linux kernel code path for devm_clk_get_optional_enabled_with_rate(). No specific release range is listed, implying that any kernel built from the repository before the patch commit is vulnerable. The patch referenced in the references resolves the issue, so kernels incorporating that commit or any later stable release that contains the change should be safe. Systems running older or custom kernel builds that have not applied this change remain at risk. Because the bug occurs in a core kernel subsystem, all userspace components that rely on the clock framework—including device drivers, device tree overlays, and kernel modules—may indirectly invoke the problematic code. Therefore, any system that loads a driver calling this function could be affected. The EPSS score is less than 1 %, indicating a very low probability of exploitation at the time of analysis, and the vulnerability is not listed in CISA’s KEV catalog. Nonetheless, the potential impact of a kernel panic warrants attention. The attack vector likely requires that the attacker can trigger a failure in setting the clock rate, which may be achieved through a compromised or malicious device driver or kernel module. Given that no publicly available exploit scripts are known, the risk remains theoretical but should be mitigated promptly to avoid future exploitation once an attacker discovers a suitable trigger.

Unpatched kernels may experience a kernel panic or intermittent failures when the cleanup path is invoked following a failed clock‑rate set. The flaw caused the cleanup routine to disable a clock that had never been enabled, potentially corrupting clock state. The EPSS score is less than 1 % and the vulnerability is not present in CISA KEV, indicating a low current exploitation probability. Nevertheless, the consequence of a kernel crash is severe, compromising system availability, and the flaw is confined to the clock management subsystem. Attackers would need to provoke the rate‑setting failure, possibly by a malicious kernel module or driver that calls devm_clk_get_optional_enabled_with_rate().