On July 30, 2026, Greg Kroah-Hartman shipped six Linux stable kernel updates in a single coordinated drop: 6.18.41, 6.12.100, 6.6.147, 6.1.180, 5.15.213, and 5.10.262. The synchronized release targeted a single root cause: a use-after-free (UAF) race condition in the POSIX CPU timers subsystem that has lived in the kernel since approximately 2010.
What the bug does
The vulnerability is a race between sys_timer_delete() and non-leader thread exec() calls. In vulnerable kernels, this race can silently disable process timers — or on multi-threaded systems, create conditions for local privilege escalation. It was independently discovered by two researchers, Wongi Lee and Jungwoo Lee, who reported it through coordinated disclosure.
POSIX CPU timers measure CPU time consumed by a process or thread. They're commonly used by profiling tools, resource accounting daemons, and real-time workloads. The affected code path triggers on any system where a thread group performs exec() while another thread is deleting a CPU timer — a pattern common enough in production services to make this non-theoretical.
Why six branches at once
The Linux kernel maintains multiple simultaneous stable and long-term support (LTS) trees, each targeting systems locked to a specific major version. The 5.10 and 5.15 branches are long-term support, maintained for embedded and enterprise systems. The 6.1 branch is LTS. The 6.6, 6.12, and 6.18 branches are current stable series. A coordinated fix across all six in one day suggests the kernel security team treated this as a formal coordinated disclosure with a fixed embargo date.
What to do
If you're running any of the affected branches (5.10, 5.15, 6.1, 6.6, 6.12, or 6.18), update now. Most major distributions — Debian, Ubuntu LTS, RHEL, SUSE — track one or more of these trees and will receive the fix through normal update mechanisms. Arch Linux, Fedora, and other distributions shipping the 7.x kernel series are unaffected by this specific patch series.
The 16-year lifespan of the bug before discovery is a reminder that subtle concurrency issues in the kernel can survive multiple major rewrites of surrounding code. Use-after-free races in timer subsystems are notoriously hard to catch in testing but reliably exploitable by a motivated local attacker with enough CPU time and patience.