posix-cpu-timers, fixed upstream in July and already carried into several stable Linux releases. For Windows administrators, the immediate question is not whether to deploy a Windows cumulative update, but whether their estate includes WSL 2, Linux virtual machines, Azure Linux hosts, Kubernetes nodes, or Linux-container infrastructure running an unpatched kernel.Microsoft’s entry gives the impact in denial-of-service terms, while the Linux kernel’s own fix explains the defect more precisely: a concurrent
exec()by a non-leader thread can leave a POSIX CPU timer attached to a process timer queue after its underlying object has been freed. Later timer activity can then dereference freed memory. The upstream patch was written by Thomas Gleixner after Wongi Lee and Jungwoo Lee reported and analyzed the race; it was merged into the Linux kernel’s timers branch on July 5 and into Linus Torvalds’ tree on July 11.
The reporting record also clears up an important timing issue. CVE trackers list CVE-2026-64560 as published on July 29, while Microsoft’s Security Update Guide entry appeared on August 9. This is a late cataloging and advisory event, not evidence of a newly discovered bug or a newly released Windows patch.
The race occurs when a non-leader thread replaces a process
The vulnerable code is part of Linux’s POSIX CPU-time timer support. These timers can be attached to a thread or an entire thread group and trigger when the target has consumed a set amount of CPU time. They are used through APIs such as
timer_create()and through CPU-clock variants of timed waits.
The unusual condition is a multithreaded process in which a thread other than the thread-group leader calls
exec(). Linux must then dismantle the old thread group and promote the calling thread into the leader role while retaining the process identity. That leader switch is legal and normal Linux behavior, but it complicates code that looks up a process by its PID and assumes the object it found will remain the current leader.
CVE-2026-64560 is triggered when timer operations race that transition. The vulnerable sequence can begin with one thread deleting or changing a CPU timer while another performs the non-leader
exec(). The timer path can obtain a reference to the old leader;
exec()then removes that leader and clears its signal-handler state. The timer operation sees the partially torn-down task and returns as if the timer has been handled, but an armed process-targeted timer can remain queued.
That leaves the kernel in the dangerous state the patch describes: the
k_itimerobject has been freed, while its queue node may still be reachable by
run_posix_cpu_timers()or by timer-queue add and delete operations. Accessing that stale node is a classic use-after-free condition. A crash or system instability is the most direct outcome, matching Microsoft’s availability-focused description.
The upstream discussion also identified a second operational symptom. One affected rearm path could silently fail, meaning a timer that should be restarted simply stopped expiring. That does not have the immediate drama of a use-after-free, but it is relevant to software depending on CPU-time limits, timing signals, or CPU-clock waits for correct behavior.
The upstream patch fixes lookup semantics, not merely one bad free
The Linux change is broader than placing another lock around
free_posix_timer(). It alters how timer code locates and locks the task associated with a CPU timer, and it introduces memory-ordering protections around task teardown.
The repaired code retries the PID-to-task lookup when it encounters the old leader with a cleared
sighandpointer. In the non-leader
exec()case, the retry should discover the newly promoted leader. In an ordinary exit, the retry fails because the process has genuinely disappeared, which is the safe point to stop touching its timer state.
The patch also adds release-and-acquire ordering around the signal-handler teardown path. This prevents a CPU from observing the
sighand == NULLstate without also observing prior cleanup of the POSIX CPU timer queues. That detail matters most on weakly ordered architectures, where seeing operations in the wrong order can turn a defensive warning into a false positive—or permit stale timer state to be used.
Linux maintainer Thomas Gleixner’s commit message adds historical context that changes the risk assessment. The underlying non-leader
exec()problem dates back to early POSIX CPU-timer designs. A 2010 workaround for multithreaded
exec()behavior lasted roughly a decade; the later change that replaced a direct task pointer with a PID reference fixed part of the original problem but missed this more subtle transition race. The vulnerable change is tracked back to Linux commit
55e8c8eb2c7b, which is why the affected version range begins at Linux 5.7.
This is not a vulnerability introduced by a recent experimental scheduler or a niche driver. It lives in a long-standing kernel facility, although reaching it requires a specific combination of CPU timers, multithreading, and a non-leader
exec()transition.
Stable kernels already contain the repair
The Linux CVE record identifies Linux kernels from 5.7 onward as affected until the relevant stable-tree fix. LWN.net reported that the July 30 stable-kernel releases contained this single CVE fix. The patched baseline versions are:
- Linux 5.10.262 for systems maintained on the 5.10 long-term-stable branch.
- Linux 5.15.213 for the 5.15 long-term-stable branch.
- Linux 6.1.180 for the 6.1 long-term-stable branch.
- Linux 6.6.147 for the 6.6 long-term-stable branch.
- Linux 6.12.100 for the 6.12 long-term-stable branch.
- Linux 6.18.41, Linux 7.1.5, and Linux 7.2-rc3 for the newer maintained and development lines.
Those numbers are useful reference points, not a universal package checklist. Enterprise distributions routinely backport individual fixes into kernels whose visible version numbers differ sharply from upstream. A Red Hat, Ubuntu, SUSE, Debian, Amazon Linux, Azure Linux, or appliance kernel may be protected even if
uname -rdoes not resemble one of those upstream versions. Conversely, a self-built kernel or a vendor image frozen before the backport remains exposed even when its distribution package name sounds current.
Administrators should check their distributor’s kernel advisory or changelog for CVE-2026-64560 and confirm that the running kernel—not merely an installed package—contains the fix. On Linux,
uname -restablishes what is currently booted; applying a kernel package without rebooting or otherwise moving workloads onto the updated host does not remove the vulnerable code from memory.
What this means for Windows, WSL, and container hosts
There is no evidence in the published record that CVE-2026-64560 affects the native Windows 10, Windows 11, or Windows Server kernel. The vulnerable files are Linux kernel components—principally
kernel/time/posix-cpu-timers.c, along with related exit and signal-handling code. Microsoft’s availability rating should therefore not be read as an instruction to hunt for a Windows KB number.
The Windows-adjacent exposure is WSL 2 and Linux-hosted infrastructure, not ordinary Windows processes. WSL 2 runs a real Linux kernel, whereas WSL 1 does not run the Linux kernel’s POSIX CPU-timer implementation. Organizations using WSL 2 for developer workstations, Docker Desktop’s WSL-backed Linux engine, or test automation should verify the kernel package Microsoft supplies for that environment and determine whether its source baseline or backports include the upstream repair.
The same distinction applies to containers. A Linux container does not bring its own kernel; it uses the host Linux kernel. Updating an application image, base distribution image, or container runtime does not by itself correct CVE-2026-64560. The remediation point is the Linux host kernel—whether that host is a bare-metal server, a cloud VM, a Kubernetes node, a WSL 2 VM, or a Docker Desktop-managed Linux environment.
Microsoft’s Security Update Guide entry does not, from the information published with the advisory, identify a Windows product, a KB article, or a specific WSL kernel build as affected. That omission leaves Windows administrators with a straightforward but important task: treat this as a Linux kernel patch-verification issue, and do not create a false sense of closure by checking Windows Update alone.
The practical consequence is immediate for teams that run Linux alongside Windows: inventory the kernels actually executing WSL 2 workloads, container hosts, Azure VMs, and Linux nodes; confirm the distributor or platform has backported CVE-2026-64560; then reboot or replace those running kernels. The vulnerable code is in the host kernel, and that is where the fix must be live.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:41 AM UTC
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: msrc.microsoft.com
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: kernel.googlesource.com
- Related coverage: vulners.com
CVE-2026-64560 - vulnerability database | Vulners.com
CVE-2026-64560 documents a Linux kernel issue in posix-cpu-timers that can cause a Use-After-Free when a timer is deleted during a non-leader exec() race. The vulnerability arises as sys_timer_delete() may observe an old leader while a leader chan...vulners.com - Related coverage: linuxcvetracker.com
CVE-2026-64560 - High Linux Kernel Vulnerability | LinuxCVETracker
CVE-2026-64560: High severity Linux kernel vulnerability (CVSS 7.8), affects Linux kernel ≥ 5.7, patch available in 5.10.262, 5.15.213, 6.1.180 and others. Published 2026-07-29.linuxcvetracker.com
