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.