CVE-2026-98535 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
fsl/fman: Fix clk reference leak in read_dts_node()
of_clk_get() returns a clock with its reference count incremented, but read_dts_node() only uses it to read the rate and never calls clk_put(). The clock is not stored anywhere, so the reference cannot be released later either.
Release the clock once its rate has been read, which also covers the error path taken when the rate is zero.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for the Freescale FMan (Frame Manager) subsystem contains a resource management flaw within the read_dts_node function that results in a persistent reference leak on clock handles obtained from the device tree infrastructure. This vulnerability stems from an asymmetry between acquiring and releasing system resources, specifically regarding how hardware clocks are managed during initialization or configuration phases. When the driver invokes of_clk_get to retrieve a handle for a specific clock identified by the device tree node, the kernel's common clock framework automatically increments the reference count associated with that clock object. This mechanism is designed to ensure that active users of a resource prevent it from being prematurely disabled or destroyed while still in use. However, the implementation within read_dts_node fails to adhere to this protocol by neglecting to call clk_put after utilizing the handle solely for reading its current rate.
This oversight creates a classic reference counting error where every invocation of the problematic code path results in an unreleased increment to the clock's internal counter. Since the retrieved clock handle is not stored in any persistent data structure within the driver, there is no subsequent opportunity to release it during cleanup or teardown routines. Consequently, each time this function executes, typically during device probing or reconfiguration events triggered by system operations such as suspend-resume cycles or dynamic module loading, a new reference remains dangling indefinitely. Over time, particularly in systems that frequently trigger these initialization sequences, the accumulation of unreleased references can lead to resource exhaustion within the clock framework. This may eventually prevent other drivers from acquiring necessary clocks, leading to broader system instability or failure to initialize dependent hardware components correctly.
From a security and stability perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective usage, although in this context it applies specifically to kernel object references rather than heap memory allocation. The flaw represents an improper resource management pattern that can degrade system performance over extended uptime periods due to the gradual depletion of available clock handles within the subsystem. While not directly exploitable for remote code execution or privilege escalation in its current form, such leaks contribute to denial-of-service conditions by exhausting kernel resources and potentially causing hardware initialization failures that render parts of the network infrastructure non-functional. The impact is primarily operational, affecting system reliability rather than confidentiality or integrity directly, but it undermines the robustness required for critical networking equipment running Linux kernels.
To mitigate this vulnerability, developers must ensure strict adherence to reference counting protocols mandated by the common clock framework. Specifically, any code path that calls of_clk_get must be paired with a corresponding call to clk_put once the handle is no longer needed. In the case of read_dts_node, the fix involves invoking clk_put immediately after the clock rate has been successfully retrieved and processed. This release should also cover error paths where the rate might be zero or invalid, ensuring that even in failure scenarios, resources are properly returned to the kernel pool. By implementing this corrective measure, the driver maintains proper resource hygiene, preventing accumulation of stale references and preserving system stability for long-running deployments.