CVE-2026-64560

What it actually does

This is a Linux kernel use-after-free in POSIX CPU timer handling during a race between timer operations and exec() in a non-leader thread. A local user can trigger a condition where a POSIX CPU timer object is freed while its timerqueue node may still be reachable from task signal state; later timer expiration, rearm, add, or delete paths can dereference the freed object. The likely outcomes are kernel memory corruption, kernel panic/denial of service, or, with sufficient heap control, local privilege escalation to kernel-level privileges. The flaw requires local code execution with low privileges and no user interaction.

Why it matters to the business

Successful exploitation can let a local user or compromised workload take control of the underlying Linux host or crash it. This is especially important for multi-user systems, shared compute, CI/CD runners, container hosts, and systems that execute untrusted code because containers share the host kernel. The issue is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no indicated public exploit maturity, which lowers immediate mass-exploitation likelihood; however, Linux kernel local privilege-escalation bugs often become valuable post-compromise tools once technical details are available.

How an attack unfolds

An attacker first needs the ability to run code locally on a vulnerable Linux system, such as through a shell account, compromised application process, container escape precondition, or untrusted workload execution. The attacker runs a multithreaded program that creates and arms POSIX CPU timers targeted at a process/thread group, then repeatedly races timer deletion or timer setting paths against exec() from a non-leader thread. In the vulnerable race, the kernel may observe an old task leader whose sighand has already been cleared during de_thread()/switch_leader() handling and return without properly removing an armed timer. The timer object can then be freed while its timerqueue node remains reachable. When CPU timer processing later walks or manipulates that timerqueue, the kernel can access freed memory. A crude exploit may cause a kernel warning, oops, or panic; a more advanced exploit would attempt to shape kernel heap reuse so the stale timerqueue pointer corrupts controlled kernel objects and yields privilege escalation.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix for the POSIX CPU timers non-leader exec() race. Because this is in kernel code, remediation normally requires installing the fixed kernel package and rebooting into it; live patching may be possible only if provided and explicitly covering this flaw. No exact fixed versions were provided in the input, so use vendor advisories for the relevant distribution, cloud image, appliance, or embedded platform to identify the corrected kernel build. Prioritize shared Linux systems, container hosts, build workers, developer jump boxes, HPC clusters, VDI/session hosts, and any system where untrusted or semi-trusted users can execute code. As temporary risk reduction, restrict local shell access, reduce untrusted workload execution, apply container isolation hardening, limit user namespaces where operationally feasible, use seccomp/AppArmor/SELinux policies to reduce unnecessary timer-related syscall exposure for high-risk sandboxed workloads, and ensure unprivileged users cannot load eBPF programs, kernel modules, or otherwise increase kernel attack surface. These mitigations reduce exploitability but do not replace patching.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated: compare uname -r and package metadata against the vendor advisory, then verify the system was rebooted or live-patched successfully. Review distribution changelogs for references to POSIX CPU timers, non-leader exec(), lock_task_sighand(), __exit_signal(), de_thread(), or use-after-free fixes. On container platforms, validate the node/host kernel version because patching container images alone does not remediate a host-kernel vulnerability. Exposure exists wherever local users, applications, containers, build jobs, or sandboxed workloads can execute code on a vulnerable kernel. Avoid using public proof-of-concept exploit code for validation on production systems; if testing is required, use vendor-provided regression tests or a controlled non-production host with crash collection enabled.

Typical attack path

1. Obtain local low-privileged code execution on a Linux host or inside a workload that shares the host kernel.
2. Run a program that creates and arms POSIX CPU timers or uses CPU-time nanosleep paths in a multithreaded process.
3. Trigger repeated races between timer_delete()/timer_settime()-like operations and exec() from a non-leader thread so the process leader changes during timer cleanup.
4. Cause the kernel to free a POSIX timer object while the timer remains logically queued in task signal/timerqueue state.
5. Wait for timer expiration or another timerqueue operation to access the freed timer object.
6. Leverage the resulting use-after-free for kernel crash/denial of service or attempt controlled kernel memory corruption for local privilege escalation.
7. If privilege escalation succeeds, establish persistence, access host secrets, tamper with workloads, or pivot to other systems.

How to detect it

Exploitation is difficult to prove from ordinary logs because the vulnerable operations occur inside kernel race conditions and may leave no clean application-level trace. Start with kernel logs and crash artifacts: dmesg, journald kernel facility, /var/log/kern.log, /var/log/messages, netconsole, pstore/ramoops, vmcore, kdump, and KASAN/KFENCE reports if enabled. Look for use-after-free, general protection faults, kernel oopses, warnings, or panics with stack traces involving POSIX CPU timer functions, timerqueue functions, de_thread(), switch_leader(), or __exit_signal(). Correlate these events with local audit telemetry showing unusual high-volume use of timer_create, timer_delete, timer_settime, clock_nanosleep, and execve from the same process tree or user account. On EDR/eBPF platforms, hunt for short-lived multithreaded processes repeatedly invoking POSIX timer syscalls and exec transitions, especially from writable directories such as /tmp, /var/tmp, /dev/shm, container overlay paths, CI workspaces, or user home directories. Also investigate any suspicious root privilege transition, new setuid file, modified sudoers entry, unauthorized SSH key, or unexpected kernel module load occurring shortly after kernel warnings or crashes. Threat actor attribution is not provided for this vulnerability, so prioritize behavior-based detection over actor-specific indicators.

• BUG: KASAN: use-after-free
• KASAN: use-after-free
• KFENCE: use-after-free
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• WARNING: CPU:
• run_posix_cpu_timers
• posix_cpu_timer_del
• posix_cpu_timer_set
• posix_cpu_timer_rearm
• posix_cpu_timers_exit
• posix_cpu_timers_exit_group
• lock_task_sighand
• timer_queued
• timerqueue_del
• timerqueue_add
• __exit_signal
• de_thread
• switch_leader
• sys_timer_delete
• timer_delete
• timer_settime
• clock_nanosleep

What your security team should do

• Inventory Linux kernels across servers, endpoints, appliances, cloud images, container nodes, and build infrastructure; identify systems running vendor builds that do not yet include the fix.
• Patch and reboot internet-facing service hosts, container hosts, shared compute, CI/CD runners, and multi-user systems first, even though exploitation requires local access.
• Treat containers as affected when the underlying host kernel is vulnerable; coordinate remediation at the node/host layer rather than only updating container images.
• Temporarily restrict untrusted local code execution and tighten sandboxing for workloads that do not need POSIX timer functionality or broad syscall access.
• Enable or review kernel crash, auditd, eBPF/EDR, and SIEM telemetry for signs of suspicious timer syscall racing, kernel oopses, or unexplained privilege escalation.
• Hunt for post-exploitation artifacts such as newly created privileged users, modified sudoers files, unexpected setuid binaries, abnormal kernel module activity, and suspicious root-owned processes following kernel warnings or crashes.
• Monitor vendor advisories and exploit intelligence because Linux kernel local privilege-escalation vulnerabilities can move from no known exploit to public proof-of-concept quickly.
• If a kernel crash or KASAN use-after-free signature is observed on a vulnerable system, preserve logs and memory/crash dumps before rebooting where operationally feasible.