CVE-2026-98826: rtc: ac100: Fix clock provider use-after-free on probe failure
In the Linux kernel, the following vulnerability has been resolved:
rtc: ac100: Fix clock provider use-after-free on probe failure
ac100rtcregisterclks() registers the RTC-32k clock with clkhwregisterfixedrate() and the clock provider with ofclkaddhwprovider(). Neither is device managed, and both are released only from ac100rtcremove(). The driver core does not call remove() when probe() fails: reallyprobe() reaches probefailed below the deviceremove() call and goes straight to releasing the device's managed resources.
ac100rtcprobe() ends with
return devmrtcregisterdevice(chip->rtc);
so if that fails after the clocks have been registered, the provider is left on the global ofclkproviders list holding chip->clkdata, which was allocated with devmkzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in ofclkhwonecellget(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100rtc 0>. The window is narrow, as devmrtcregisterdevice() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.
The RTC-32k clock is leaked on the same path. Since clkcorelookup() searches a global list that is not scoped per device, clkregister() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail.
The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free.
Register both with devmclkhwregisterfixedrate() and devmofclkaddhwprovider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clkdata is freed, and the clkout children are now unregistered before their parent rather than after it. ac100rtcunregisterclks() and the remove callback then have nothing left to do and are removed.
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to be exposed to this issue?
Systems using the AC100 RTC driver and device tree clock consumers that reference the AC100 RTC are relevant. The description identifies Wi-Fi power-sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus, plus sun9i-a80 boards that route osc32k through the AC100 RTC.
What must happen for the use-after-free to occur?
The AC100 RTC probe must fail after its clocks and clock provider have been registered, specifically when devm_rtc_register_device() fails. A later clock lookup for that device tree node can then access the freed clock data through the still-registered provider.
Are normally successful driver initializations affected?
The described condition is limited to probe failure after clock registration; the window is described as narrow. The issue arises because probe failure does not invoke the driver's remove() routine, leaving non-device-managed clock registrations behind.
How can an affected system be identified from runtime behavior?
Look for an AC100 RTC probe failure followed by a later lookup of a clock provided by the same AC100 RTC device tree node. The resulting access occurs in of_clk_hw_onecell_get() through a provider retaining freed chip->clk_data.