CVE-2026-98848: rtc: ac100: Assign .num before accessing .hws
In the Linux kernel, the following vulnerability has been resolved:
rtc: ac100: Assign .num before accessing .hws
Commit f316cdff8d67 ("clk: Annotate struct clkhwonecelldata with countedby") annotated the hws member of 'struct clkhwonecelldata' with countedby, which informs the bounds sanitizer (UBSANBOUNDS) about the number of elements in .hws[], so that it can warn when .hws[] is accessed out of bounds. As noted in that change, the countedby member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in ac100rtcregisterclks() due to .num being assigned only after every clkout clock has been stored in .hws[]. With CONFIGUBSANBOUNDS and a compiler that implements countedby (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe, and with CONFIGUBSANTRAP the first store traps.
Initialize .num with AC100CLKOUTNUM, the number of elements .hws[] was allocated with, right after the allocation. That is the value the loop counter ends up at on the success path anyway, so the provider's behaviour is unchanged.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch f316cdff8d67
Event History
Frequently Asked Questions
Which systems are likely to encounter this issue?
Systems that probe the AC100 RTC clock driver are affected when built with CONFIG_UBSAN_BOUNDS and a compiler implementing __counted_by support, specifically GCC 15.1 or later or Clang 20.1 or later.
What is the practical impact during device initialization?
The driver can emit an array-index-out-of-bounds report during probe. If CONFIG_UBSAN_TRAP is enabled, the first store to the clock hardware array traps, which can prevent the driver from completing initialization.
How can I determine whether the issue is occurring?
Check kernel logs during AC100 RTC driver probe for an array-index-out-of-bounds report. On systems with CONFIG_UBSAN_TRAP enabled, look for a trap occurring at the first store to the clock hardware array.
What configuration condition makes exploitation or triggering possible?
Triggering requires the AC100 RTC clock registration path to run and CONFIG_UBSAN_BOUNDS to be enabled with a supporting compiler. The described behavior is caused by accessing the hws array before its num count is initialized.