CVE-2026-80927: timekeeping: Check the return value of tk_get_aux_ts64 in __do_adjtimex()
In the Linux kernel, the following vulnerability has been resolved:
timekeeping: Check the return value of tkgetauxts64 in doadjtimex()
If the auxiliary clock is disabled during tkgetauxts64() but is enabled before tks->clockvalid 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.
Event History
Frequently Asked Questions
What conditions are required for the information leak to occur?
The auxiliary clock must be disabled while tk_get_aux_ts64() is running and then enabled again before tks->clock_valid is checked. This race can cause uninitialized stack data to be used in calculations and indirectly exposed to userspace.
Is the core timekeeper affected by the same information-leak behavior?
A similar race window exists for the core timekeeper, but the stated effect there is incorrect adjustments rather than leakage of uninitialized stack data. Avoiding those incorrect adjustments is described as a userspace responsibility.
How can the issue be mitigated if the fix cannot be applied immediately?
Avoid userspace operations that disable and re-enable the auxiliary clock during the relevant time-adjustment operation. This reduces exposure to the race that can lead to uninitialized stack data being indirectly leaked.