CVE-2026-90126 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf8563: fix clock provider leak on unbind
pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference.
The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel driver for the PCF8563 real-time clock involves a resource leak within the clock provider registration mechanism. Specifically, the function pcf8563_clkout_register_clk() utilizes of_clk_add_provider to register the CLKOUT clock provider with the device tree subsystem. This operation allocates an internal struct of_clk_provider object, acquires a reference count on the associated Open Firmware node, and inserts an entry into the global list of clock providers managed by the kernel. However, the driver implementation lacks a corresponding cleanup routine during the unbind phase or module removal process. Consequently, there is no invocation of of_clk_del_provider to reverse these allocations and references, resulting in persistent memory leaks every time the device is bound and subsequently unbound, or when the kernel module is reloaded.
From an operational perspective, this flaw leads to a gradual depletion of kernel memory resources over repeated bind-unbind cycles or driver reloads. While individual leak sizes may be small, the cumulative effect can contribute to system instability or performance degradation in environments where devices are frequently hot-plugged or drivers are dynamically loaded and unloaded. The lack of proper teardown logic means that orphaned provider structures remain allocated in kernel space, holding onto references to device tree nodes that should otherwise be released when the hardware connection is severed. This represents a classic failure in resource management lifecycle handling within kernel driver code.
The technical root cause lies in the asymmetry between resource acquisition and release mechanisms used by the driver. While the clock registration itself was correctly implemented using devm_clk_register, which ensures automatic cleanup via device-managed resources, the provider registration step remained outside this managed scope. The fix addresses this discrepancy by replacing of_clk_add_provider with devm_of_clk_add_hw_provider. This change ties the lifetime of the clock provider to that of the parent I2C device. Since the RTC class device does not possess its own Open Firmware node, tying the resource management to the parent ensures that when the parent device is removed or unbound, the kernel automatically invokes the necessary cleanup routines to delete the provider and release the OF node reference.
This vulnerability aligns with CWE-401, which describes a missing release of memory after effective usage, specifically in the context of dynamic resource allocation without corresponding deallocation logic. In terms of attack surface and potential impact, while primarily a reliability issue rather than a direct security exploit vector for privilege escalation or remote code execution, it falls under broader categories of software defects that can lead to denial-of-service conditions through resource exhaustion. It does not directly map to specific ATT&CK techniques as it is an internal kernel stability flaw rather than an external attack pattern, but it reflects poor adherence to secure coding practices regarding lifecycle management of system resources.
To mitigate this vulnerability and prevent future occurrences, developers must ensure that all calls to provider registration functions like of_clk_add_provider are paired with corresponding deletion calls in the driver's remove or unbind callbacks. Alternatively, leveraging device-managed resource APIs such as devm_of_clk_add_hw_provider is recommended for automatic cleanup upon device detachment. This approach reduces boilerplate code and minimizes the risk of human error in manual memory management. System administrators should apply kernel updates that include this patch to restore proper resource accounting integrity for systems utilizing PCF8563 hardware or similar drivers with analogous implementation flaws.