PT-2026-117045 · Linux · Linux

CVE-2026-98826

·

Published

2026-10-18

·

Updated

2026-10-18

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
rtc: ac100: Fix clock provider use-after-free on probe failure
ac100 rtc register clks() registers the RTC-32k clock with clk hw register fixed rate() and the clock provider with of clk add hw provider(). Neither is device managed, and both are released only from ac100 rtc remove(). The driver core does not call remove() when probe() fails: really probe() reaches probe failed below the device remove() call and goes straight to releasing the device's managed resources.
ac100 rtc probe() ends with
return devm rtc register device(chip->rtc);
so if that fails after the clocks have been registered, the provider is left on the global of clk providers list holding chip->clk data, which was allocated with devm kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of clk hw onecell get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100 rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100 rtc 0>. The window is narrow, as devm rtc register device() 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 clk core lookup() searches a global list that is not scoped per device, clk register() 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 devm clk hw register fixed rate() and devm of clk add hw provider() 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->clk data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100 rtc unregister clks() and the remove callback then have nothing left to do and are removed.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98826

Affected Products

Linux