CVE-2024-49985 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume
In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/21/2026
The vulnerability described in CVE-2024-49985 represents a critical deadlock condition within the Linux kernel's I2C subsystem, specifically affecting the stm32f7 I2C driver implementation. This issue manifests when clock controllers are connected to the I2C bus, creating a circular dependency that results in system lockup. The problem occurs during runtime suspend and resume operations when the kernel attempts to manage clock states for I2C devices that are controlled by external clock controllers such as Versaclock or AIC32x4 I2C codecs. The deadlock mechanism involves the prepare_lock mutex in the clock subsystem, which creates an impossible circular dependency scenario.
The technical flaw stems from improper clock management during runtime transitions within the I2C driver's suspend/resume handling code. When a clock controller attempts to prepare a clock through its clk_ops .prepare callback, it first acquires the prepare_lock mutex from the kernel's clock subsystem. During this preparation process, the clock controller performs I2C operations to configure the clock, which triggers the I2C bus controller's .runtime_resume callback. This callback then attempts to enable the clock using clk_prepare_enable(), which again tries to acquire the same prepare_lock mutex, resulting in an immediate deadlock situation. This circular dependency violates standard kernel locking protocols and creates a system-wide freeze condition.
The operational impact of this vulnerability is severe as it can cause complete system hang or crash when clock controllers attempt to manage I2C-based clock sources during runtime transitions. Systems using stm32f7 I2C controllers with external clock management hardware become vulnerable to these deadlocks, potentially affecting embedded systems, industrial control equipment, and any device relying on clock controllers that communicate via I2C. The vulnerability particularly affects devices where clock controllers need to perform I2C operations during prepare and enable operations, making it a critical issue for embedded Linux systems that depend on precise clock management and I2C communication between clock and peripheral components.
The fix implemented addresses this issue by modifying the clock management approach during runtime suspend and resume operations. Instead of using clk_prepare_enable() and clk_prepare_disable() functions that trigger the problematic prepare_lock mutex acquisition, the solution employs simple clk_enable() and clk_disable() calls that bypass the prepare_lock contention. This change ensures that clocks remain prepared from the probe() function and unprepared only during remove(), while runtime operations use basic enable/disable mechanisms that avoid the mutex deadlock. The solution aligns with CWE-362, which describes concurrent execution using shared resources without proper synchronization, and addresses ATT&CK technique T1490, which covers denial of service through resource exhaustion or locking mechanisms. This remediation maintains the necessary clock functionality while eliminating the circular dependency that caused the system-level deadlock condition.