CVE-2026-98848 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
rtc: ac100: Assign .num before accessing .hws
Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer (UBSAN_BOUNDS) 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 __counted_by 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 ac100_rtc_register_clks() due to .num being assigned only after every clkout clock has been stored in .hws[]. With
CONFIG_UBSAN_BOUNDS and a compiler that implements __counted_by (GCC 15.1+ or Clang 20.1+), this triggers an array-index-out-of-bounds report during probe, and with CONFIG_UBSAN_TRAP the first store traps.
Initialize .num with AC100_CLKOUT_NUM, 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability described involves a critical initialization order error within the Linux kernel’s real-time clock driver for the AC100 chip, specifically in the function ac100_rtc_register_clks. This issue stems from an interaction between recent compiler enhancements and kernel memory safety instrumentation. Specifically, commit f316cdff8d67 introduced annotations to struct clk_hw_onecell_data using the __counted_by attribute. This attribute is designed to inform the Undefined Behavior Sanitizer (UBSAN_BOUNDS) about the valid bounds of the hws array member. The purpose of this annotation is to enable runtime detection of out-of-bounds accesses, thereby preventing potential memory corruption or information leakage that could arise from accessing elements beyond the allocated limit. However, for these safety checks to function correctly without generating false positives, the __counted_by field must be initialized with the correct count before any access to the annotated array occurs.
In the affected code path, the .num member of struct clk_hw_onecell_data was being assigned only after a loop had completed storing clock hardware structures into the .hws array. Because this assignment happened subsequent to the initial accesses during the registration process, the sanitizer perceived the array as having zero valid elements at the time of those first accesses. Consequently, when compiled with CONFIG_UBSAN_BOUNDS enabled and using modern compilers such as GCC 15.1 or later, or Clang 20.1 and later that support __counted_by, each access to .hws prior to the initialization triggers an array-index-out-of-bounds warning from UBSAN. In configurations where CONFIG_UBSAN_TRAP is active, this condition results in a trap exception during the probe phase of the driver, effectively causing a denial of service by preventing the device from initializing correctly.
From a technical perspective, this flaw represents a classic initialization race or ordering error rather than an exploitable buffer overflow in the traditional sense, as the access remains within allocated memory limits but violates the semantic bounds defined for safety instrumentation. The vulnerability aligns with CWE-665, which describes improper initialization of public data members, and can be contextualized under ATT&CK technique T1083, file discovery or system information gathering if one considers that a failed probe might leak driver state or prevent normal system operation leading to availability impact. Although the immediate effect is primarily operational disruption due to kernel warnings or traps during device probing, such issues highlight broader risks related to memory safety in low-level systems programming where incorrect assumptions about data structure states can lead to unpredictable behavior under strict sanitization regimes.
The resolution involves reordering the initialization sequence so that .num is set to AC100_CLKOUT_NUM immediately after the allocation of the hws array, rather than waiting until all elements have been populated. This adjustment ensures that the __counted_by annotation accurately reflects the number of available elements from the very first access point in the loop. Since the final value assigned to .num on a successful execution path is identical to AC100_CLKOUT_NUM, this change does not alter the functional behavior of the provider but strictly adheres to the requirements imposed by modern memory safety tools. This fix mitigates the false positive reports from UBSAN and prevents potential traps in debug configurations, thereby restoring stable operation for systems relying on this RTC driver while maintaining compliance with contemporary kernel security standards.