Re: [PATCH] rtc: ac100: Assign .num before accessing .hws
From: Aamir Ahmed
Date: Sat Sep 05 2026 - 16:46:05 EST
On Sat, Sep 05, 2026 at 06:49:35PM +0000, Sashiko AI wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but does the lack of cleanup
> in ac100_rtc_probe() lead to a use-after-free and resource leak?
[...]
> Can any subsequent attempt to query a clock via device tree traverse the
> provider list, dereference the freed pointer, and trigger a crash?
Yes, I think that is correct, thanks for pointing it out.
ac100_rtc_register_clks() registers the RTC-32k clock and the clock
provider without devres, and both are released only from
ac100_rtc_remove(). really_probe() reaches probe_failed below the
device_remove() call, so remove() does not run when probe() fails, and
chip->clk_data is then freed by devres_release_all() while the provider
still points at it. A later lookup on that node would read freed memory
in of_clk_hw_onecell_get(). There are real consumers: 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 RTC-32k clock is leaked on the same path, and since __clk_register()
rejects a duplicate name with -EEXIST that also makes a later probe of
the same device fail.
The -EINVAL path taken when the ADDA 4M parent clock cannot be found
leaks the RTC-32k clock too, but no provider has been registered at that
point, so that one is a leak rather than a use-after-free. It also is
not reachable with any in-tree device tree, since every board points the
rtc node at the codec node.
On the rating: I do not think High is right. devm_rtc_register_device()
can only fail with -ENOMEM here, nothing on that path is influenced by
an unprivileged user, and re-opening the window needs a root-initiated
rebind. Per Documentation/process/threat-model.rst I would treat it as a
regular error-path bug rather than a vulnerability, which is also how
the equivalent fixes in rtc-jz4740 and rtc-pcf8563 were handled.
I have sent a separate patch converting both registrations to
devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider(),
which also lets ac100_rtc_unregister_clks() and the remove callback go
away:
rtc: ac100: Fix clock provider use-after-free on probe failure
It applies on top of this one. It is compile-tested only, as I do not
have AC100 hardware.
Thanks,
Aamir