Cloudanix VulnDB

CVE-2026-80927

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the operating system kernel can let an attacker read leftover memory fragments that should have stayed private.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in timekeeping allows uninitialized stack data to be used in calculations and indirectly leaked to userspace when auxiliary clock state changes between tk_get_aux_ts64 and clock_valid check.

Why it matters to the business

Attackers may obtain fragments of sensitive kernel memory, increasing risk of credential or data exposure on affected Linux systems.

How an attack unfolds

An attacker invokes the adjtimex syscall while concurrently toggling the auxiliary clock state to hit the race window, causing uninitialized stack contents to be processed and returned to userspace.

How to fix it

Apply the upstream kernel patch that adds proper return-value checking for tk_get_aux_ts64 and ensure clock state is consistently validated before use.

How to confirm the fix worked

Review kernel source for the added return-value check on tk_get_aux_ts64 inside __do_adjtimex and confirm the patch is present in running kernel via source inspection or package changelog.

Typical attack path

  1. Identify system exposing adjtimex interface
  2. Disable auxiliary clock
  3. Invoke adjtimex syscall
  4. Re-enable auxiliary clock before clock_valid check
  5. Observe leaked stack data in returned values

How to detect it

Examine kernel audit logs and syscall traces for unusual adjtimex patterns coinciding with auxiliary clock configuration changes; look for anomalous time-adjustment values returned to processes.

What your security team should do

  • Prioritize kernel updates containing the timekeeping race fix on all production systems
  • Monitor upstream stable and distribution kernel releases for backports
  • Review any custom timekeeping or adjtimex usage for similar race assumptions

The record

In the Linux kernel, the following vulnerability has been resolved: timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex() If the auxiliary clock is disabled during tk_get_aux_ts64() but is enabled before tks->clock_valid is checked, then uninitialized stackdata will be used in the calculations and indirectly leaked to userspace. The same race window also exists after this change and also for the core timekeeper. But in these cases the only effect would be incorrect adjustments and this is userspace's responsibility to avoid this.

Affected packages

Ecosystem Package Introduced Fixed