CVE-2026-99161 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
i2c: viai2c-wmt: Fix clock leak in wmt_i2c_probe()
In wmt_i2c_probe(), i2c->clk is acquired using of_clk_get(). If any subsequent operation fails or when the module is unloaded, the clock reference count is never decremented via clk_put(), leading to a resource leak.
Switch to devm_clk_get() so that the clock is automatically managed and released.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in the Linux kernel involves an improper resource management issue within the i2c: viai2c-wmt driver, specifically during the initialization phase of the WMT I2C controller. The core technical flaw resides in the wmt_i2c_probe function, where the clock handle for the hardware is acquired using the standard of_clk_get API. This acquisition increments a reference count to ensure the clock resource remains active and available for subsequent operations. However, the original implementation failed to establish a corresponding cleanup path that would decrement this reference count by calling clk_put under all necessary conditions. Specifically, if any operation following the clock acquisition fails during the probe sequence, or when the driver module is subsequently unloaded from the kernel space, the allocated clock resource was not released. This oversight results in a persistent resource leak where the kernel retains ownership of the hardware clock even after it should have been freed, preventing other drivers or subsystems from utilizing that specific clock line and potentially leading to system instability over time as more resources are consumed without release.
From a security and stability perspective, this defect is classified under CWE-401, which denotes a missing release of memory or other resource after its effective use. While not directly exploitable for remote code execution in the traditional sense, such leaks contribute to long-term system degradation known as resource exhaustion. In environments where drivers are frequently loaded and unloaded during development or dynamic configuration changes, these leaked references accumulate rapidly. Over time, this can lead to a state where critical hardware resources become unavailable, causing peripheral devices to fail unexpectedly or preventing new instances of the driver from initializing correctly. This aligns with ATT&CK technique T1496, Resource Hijacking, as the unmanaged resource consumption effectively denies access to system components for legitimate processes that require those specific clock signals.
The resolution implemented in this fix transitions the codebase from using the manual management API of_clk_get to the device-managed variant devm_clk_get. This architectural change leverages the kernel's device resource management framework, which automatically tracks resources allocated during a driver's probe phase and ensures they are released when the associated device is detached or removed. By adopting this pattern, the need for explicit error handling paths dedicated solely to clock cleanup is eliminated, significantly reducing code complexity and eliminating the possibility of human error in maintaining reference counts. This approach not only fixes the immediate leak but also improves the overall robustness of the driver by ensuring that resource lifecycles are strictly tied to device lifecycle events rather than manual intervention.
To mitigate similar issues across other kernel subsystems, developers should prioritize the use of managed resource APIs such as devm_ variants for all allocations including memory, clocks, IRQs, and platform data. This practice ensures automatic cleanup upon driver removal or probe failure. Additionally, static analysis tools configured to detect missing clk_put calls in error paths can help identify these vulnerabilities early in the development cycle. For existing systems running affected kernels, applying the latest kernel patches that include this fix is essential to restore proper resource accounting and maintain system stability. Regular auditing of driver code for adherence to device-managed patterns serves as a preventive measure against future occurrences of similar resource leaks.