CVE-2026-80927: Linux Kernel Information Disclosure Vulnerability

CVE-2026-80927 Overview

CVE-2026-80927 is a race condition in the Linux kernel timekeeping subsystem. The flaw resides in the __do_adjtimex() function, which fails to check the return value of tk_get_aux_ts64(). When the auxiliary clock is disabled during tk_get_aux_ts64() but re-enabled before tks->clock_valid is evaluated, the kernel uses uninitialized stack data in subsequent calculations. That stack data is then indirectly leaked to userspace through the adjtimex interface.

Critical Impact
Local userspace processes can indirectly obtain uninitialized kernel stack contents through a race window in the timekeeping code, enabling potential information disclosure.

Affected Products

Linux kernel (upstream) versions containing the auxiliary clock timekeeping code prior to the fix commits
Linux distributions shipping affected kernel builds
Stable kernel trees referenced by the upstream fix commits

Discovery Timeline

2026-09-11 - CVE-2026-80927 published to the National Vulnerability Database (NVD)
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-80927

Vulnerability Analysis

The issue is a Time-of-Check Time-of-Use (TOCTOU) race in kernel timekeeping. __do_adjtimex() calls tk_get_aux_ts64() to retrieve auxiliary clock timestamps. The function does not inspect the return value of that call. If the auxiliary clock is disabled at the moment tk_get_aux_ts64() executes, the timestamp structure remains uninitialized on the stack.

A later check of tks->clock_valid may succeed if the clock is re-enabled between the retrieval and the validity check. The kernel then proceeds to use the uninitialized stack values in its adjustment calculations. Portions of that uninitialized data flow back into structures returned to userspace, resulting in indirect kernel memory disclosure.

The upstream commit note explicitly acknowledges that a similar race window remains for the core timekeeper after the fix, but in that case the outcome is limited to incorrect time adjustments rather than information leakage. Userspace is expected to coordinate concurrent adjtimex calls to avoid that scenario.

Root Cause

The root cause is a missing return-value check combined with a TOCTOU window. tk_get_aux_ts64() can fail silently when the auxiliary clock is disabled, leaving stack-allocated timestamp fields uninitialized. Because __do_adjtimex() does not verify success before consuming those fields, uninitialized memory feeds arithmetic that ultimately surfaces in user-observable output.

Attack Vector

A local unprivileged process can invoke adjtimex() or clock_adjtime() repeatedly while toggling auxiliary clock state, or race against another process performing such toggling. Successful exploitation requires winning a narrow scheduling window between the auxiliary clock read and the clock_valid check. The result is partial disclosure of kernel stack contents, which may include pointers or other data useful for defeating Kernel Address Space Layout Randomization (KASLR).

No public proof-of-concept has been published, and no evidence of exploitation in the wild has been recorded. See the upstream fix commits referenced below for technical detail: Kernel Git Commit 4b61084, Kernel Git Commit bc59dac5, and Kernel Git Commit fecf1e37.

Detection Methods for CVE-2026-80927

Indicators of Compromise

No file-based indicators exist because exploitation leaves no persistent artifacts on disk.
Anomalously high volumes of adjtimex() or clock_adjtime() syscalls from unprivileged processes may indicate probing.
Repeated user-driven toggling of auxiliary clock state combined with timekeeping syscalls should be treated as suspicious.

Detection Strategies

Instrument syscall auditing with auditd rules on adjtimex and clock_adjtime to establish baseline call rates per user and process.
Deploy eBPF-based tracing to correlate auxiliary clock state changes with adjtimex-family syscalls in tight loops.
Compare running kernel versions against the upstream fix commits to identify hosts still exposed.

Monitoring Recommendations

Monitor kernel package versions across the fleet and flag hosts running unpatched kernels containing the auxiliary clock code path.
Collect and centralize syscall telemetry to a security data lake for retrospective hunting once patches are deployed.
Alert on non-root processes issuing high-frequency timekeeping syscalls outside of known NTP or chrony workloads.

How to Mitigate CVE-2026-80927

Immediate Actions Required

Inventory all Linux hosts and identify kernel versions exposed to the vulnerable code path.
Apply vendor-supplied kernel updates that incorporate the upstream fix commits as soon as they are available for your distribution.
Reboot affected systems after patch installation so the fixed kernel is active.
Restrict local access to trusted users on systems that cannot be immediately patched.

Patch Information

The issue is resolved upstream by three commits in the stable kernel tree: Kernel Git Commit 4b61084, Kernel Git Commit bc59dac5, and Kernel Git Commit fecf1e37. The fix adds a return-value check for tk_get_aux_ts64() in __do_adjtimex() so that uninitialized stack data is never consumed when the auxiliary clock read fails. Consult your distribution's security tracker for backported package versions.

Workarounds

No official workaround has been published; kernel replacement is the supported remediation.
Where patching is delayed, limit local shell access and enforce least privilege for interactive users to reduce exposure to local information disclosure.
Consider seccomp filters that restrict adjtimex and clock_adjtime for workloads that do not require time adjustment capabilities.

bash

# Verify running kernel version and check against distribution advisories
uname -r

# Example seccomp-style restriction reference (adjust for your workload manager)
# Deny adjtimex and clock_adjtime for unprivileged service accounts
# See systemd SystemCallFilter= or container runtime seccomp profiles