Cloudanix VulnDB

CVE-2026-98848

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small initialization mistake in a clock setup routine inside the Linux kernel can cause boot warnings or crashes on certain development builds but does not let attackers take control of the system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Failure to initialize the __counted_by member of clk_hw_onecell_data before writing into the hws array causes UBSAN_BOUNDS to report (or trap on) out-of-bounds stores during rtc-ac100 clock registration.

Why it matters to the business

Systems built with recent compilers and kernel UBSAN options may fail to boot or log repeated warnings when the affected RTC driver probes, increasing test and validation effort for distributions and embedded devices.

How an attack unfolds

An attacker would need local ability to trigger the ac100 RTC driver probe on a kernel compiled with CONFIG_UBSAN_BOUNDS and a compiler supporting __counted_by; the flaw itself only produces a sanitizer diagnostic and does not provide memory corruption usable for code execution.

How to fix it

Apply the upstream fix that sets .num = AC100_CLKOUT_NUM immediately after allocation; rebuild and deploy the corrected kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting ac100_rtc_register_clks() for the assignment of .num before the loop; boot a UBSAN_BOUNDS kernel and verify the driver probes without sanitizer reports.

Typical attack path

  1. Load or trigger the rtc-ac100 driver on a UBSAN_BOUNDS kernel
  2. Driver allocates clk_hw_onecell_data without setting .num first
  3. Loop writes clock pointers into .hws[] while .num remains zero
  4. UBSAN_BOUNDS detects the access and either warns or traps

How to detect it

Examine kernel logs for UBSAN_BOUNDS array-index-out-of-bounds reports originating from ac100_rtc_register_clks during early boot; no persistent artifacts remain after the warning or trap.

What your security team should do

  • Merge the referenced commit into all maintained kernel branches that include the rtc-ac100 driver
  • Rebuild and test kernels with CONFIG_UBSAN_BOUNDS enabled
  • Prioritize updates for distributions and devices that ship the ac100 RTC driver

The record

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.

Affected packages

Ecosystem Package Introduced Fixed