CVE-2026-23106: 
Linux Kernel vulnerability analysis and mitigation

CVE-2026-23106 is a Linux kernel vulnerability in the timekeeping subsystem where the leap state adjustment incorrectly targets the core timekeeper instead of the auxiliary timekeeper when __do_adjtimex() is called on an auxiliary clock. This flaw was published on February 4, 2026, and affects Linux kernel versions from 6.17 up to (but not including) 6.18.8, as well as 6.19 release candidates rc1 through rc6. It carries a CVSS v3.1 base score of 5.5 (Medium), with availability impact only and requiring low-privileged local access (Feedly).

The root cause is an incorrect reference to tk_core (the global core timekeeper) within __do_adjtimex() that was not updated when the function was refactored to support auxiliary timekeepers (CWE-667: Improper Locking). When clock_adjtime() is invoked on an auxiliary clock, the function writes the leap state to the core timekeeper's sequence lock without holding the associated spinlock, violating the lock discipline and triggering a kernel warning via lock debugging diagnostics (WARNING: include/linux/seqlock.h:226). The call path is: aux_clock_adj → __do_adjtimex → incorrect write to core tk_core seqlock. Exploitation requires local access with sufficient privileges to call clock_adjtime(2) on an auxiliary clock (Feedly).

Successful exploitation causes incorrect modification of the core timekeeper's leap state, leading to potential system instability or a kernel denial-of-service condition. The availability impact is rated High, while there is no confidentiality or integrity impact. Systems relying on precise timekeeping (e.g., NTP-synchronized servers, financial or real-time systems) may experience time synchronization errors or kernel panics under lock debugging configurations (Feedly).

The Linux kernel maintainers have released patches addressing this issue. Users should upgrade to Linux kernel version 6.18.8 or later, or apply the 6.19-rc7 patch for pre-release kernels. Two upstream commits address the issue: 8f7c9dbeaa0b and e806f7dde8ba. As a temporary workaround, restricting unprivileged access to clock_adjtime(2) via system call filtering (e.g., seccomp) can reduce exposure until patching is feasible (Feedly).