CVE-2026-90126: rtc: pcf8563: fix clock provider leak on unbind
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf8563: fix clock provider leak on unbind
pcf8563clkoutregisterclk() registers the CLKOUT clock provider with ofclkaddprovider(), but nothing ever unwinds it: there is no ofclkdelprovider() call and the driver has no remove callback. Each ofclkaddprovider() allocates a struct ofclkprovider, takes a reference on the OF node and adds an entry to the global ofclkproviders list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an ofnode reference.
The clock itself is already device-managed (devmclkregister()); only the provider registration was not. Use devmofclkaddhwprovider() 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the affected driver/provider code path (e.g., pcf8563_clkout_register_clk()) to register the clock provider using devm_of_clk_add_hw_provider() tied to the parent device/of_node reference, so the provider structure allocated by of_clk_add_provider is automatically unwound/removed when the device is unbound (preventing the provider structure and i2c device leak).
Linux kernel clock provider (devm_of_clk_add_hw_provider / of_clk_add_provider) provider registration lifecycle on device unbind = Use devm_of_clk_add_hw_provider() with an of_node reference instead of of_clk_add_provider(); ensure provider is devm-managed so it is removed automatically on unbind (no need for of_clk_del_provider(), and avoid missing remove callback).
Event History
Frequently Asked Questions
When does this leak occur?
The leak occurs each time the PCF8563 driver is bound and then unbound, including through module reloads. Each cycle leaves behind a clock-provider structure and a reference to the device-tree node.
What systems are exposed to the leak?
Systems using the PCF8563 RTC driver with its CLKOUT clock provider registered through the parent I2C device's device-tree node are affected. The relevant device-tree node carries the #clock-cells and clock-output-names properties.
Is the clock object itself leaked?
No. The clock is device-managed through devm_clk_register(); the leaked resources are the clock-provider registration and its OF-node reference.
What changes prevent the leak?
The provider registration must be device-managed so it is removed during unbind. Using devm_of_clk_add_hw_provider() tied to the parent I2C device ensures automatic cleanup.