CVE-2026-98826
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A timing problem in a Linux kernel clock driver for certain chips can let memory that should already be freed be read again if the driver fails to start, which could cause crashes or leaks on affected devices.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Use-after-free in the ac100 RTC driver where clk_hw_register_fixed_rate and of_clk_add_hw_provider register non-devm resources that remain on global lists after devm-managed chip data is freed on probe failure paths, allowing subsequent of_clk_hw_onecell_get lookups to dereference freed memory.
Why it matters to the business
On affected Allwinner systems, driver initialization failures can leave dangling clock providers that cause later kernel memory reads, potential crashes, or duplicate registration errors preventing normal RTC and dependent device operation such as WiFi power sequencing.
How an attack unfolds
An attacker with local access forces the ac100_rtc_probe function to fail after registering clocks but before devm_rtc_register_device succeeds, then triggers a clock lookup from device-tree consumers; the freed chip data is read from the global of_clk_providers list.
How to fix it
Update to a kernel containing the fix that replaces clk_hw_register_fixed_rate and of_clk_add_hw_provider with their devm_ equivalents so resources are released automatically on any probe failure or device removal.
How to confirm the fix worked
Confirm the driver source uses devm_clk_hw_register_fixed_rate and devm_of_clk_add_hw_provider; attempt to induce probe failure via memory pressure and verify no dangling providers remain on the of_clk_providers list.
Typical attack path
- Trigger conditions that cause ac100_rtc_probe to allocate clk_data and register clocks via non-devm APIs
- Cause devm_rtc_register_device to return -ENOMEM after registration but before probe returns success
- Trigger a later of_clk_get or clk lookup from a consumer node referencing the ac100 provider
- Read freed memory in of_clk_hw_onecell_get or trigger duplicate name rejection on subsequent probe attempts
How to detect it
Inspect kernel logs for ac100_rtc probe failures followed by of_clk or clk_core_lookup warnings; search dmesg or serial console output for use-after-free reports or -EEXIST on duplicate clock names during subsequent probe attempts.
What your security team should do
- Apply the upstream fix or vendor kernel update containing the devm registration changes as soon as available
- Monitor for kernel oops or warnings referencing ac100_rtc or of_clk_hw_onecell_get on affected hardware
- Limit local unprivileged access on systems using the ac100 RTC until patched
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|