Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-64560

CVE-2026-64560: Linux Kernel Use-After-Free Vulnerability

CVE-2026-64560 is a use-after-free vulnerability in the Linux kernel's posix-cpu-timers that can be triggered by non-leader exec() races. This article covers the technical details, affected versions, and mitigation strategies.

Published:

CVE-2026-64560 Overview

CVE-2026-64560 is a use-after-free (UAF) vulnerability in the Linux kernel's posix-cpu-timers subsystem. The flaw arises from a race condition between sys_timer_delete() and a non-leader thread invoking exec(), where de_thread() switches the group leader and releases the old leader task. During this window, posix_cpu_timer_del() can observe the old leader with a NULLsighand and return without dequeuing an armed TGID-targeted timer. Subsequent operations on the freed timer object corrupt the timerqueue, producing memory safety violations that a local attacker can leverage for privilege escalation or denial of service.

Critical Impact

Local attackers with the ability to arm POSIX CPU timers and trigger a non-leader exec() can induce kernel memory corruption, enabling privilege escalation or denial of service on unpatched Linux systems.

Affected Products

  • Linux kernel (multiple stable branches, prior to the fixes referenced in the kernel.org commits)
  • Distributions shipping vulnerable Linux kernel versions
  • Systems running workloads that use POSIX CPU timers with multi-threaded processes performing exec()

Discovery Timeline

  • 2026-07-29 - CVE-2026-64560 published to NVD
  • 2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-64560

Vulnerability Analysis

The vulnerability is a race condition leading to a use-after-free in the Linux kernel posix-cpu-timers code path. When a non-leader thread performs exec(), de_thread() calls switch_leader() and then release_task() on the old leader, which in turn invokes __exit_signal(). __exit_signal() acquires the sighand lock, calls posix_cpu_timers*_exit(), unhashes the old leader task, and sets old_leader->sighand = NULL.

Concurrently, a thread executing sys_timer_delete() calls posix_cpu_timer_del(), looks up the task via pid_task(), and observes the now-defunct old leader. When it calls lock_task_sighand(p), the observed sighand is NULL, causing the function to return without dequeuing the timer. Because a TGID-targeted timer is inherited across exec(), the timer remains enqueued in p->signal and subsequent run_posix_cpu_timers() or timerqueue operations dereference the freed timer object.

A companion issue affects posix_cpu_timer_set() and do_cpu_nanosleep(), where the same race can dereference a k_itimer allocated on the stack. On weakly ordered architectures, the read of p->sighand == NULL is not guaranteed to observe prior stores from posix_cpu_timers*_exit(), producing false-positive WARN_ON_ONCE triggers and undefined behavior.

Root Cause

The root cause is insufficient memory ordering and missing retry logic in the task lookup used by posix_cpu_timer_del(), posix_cpu_timer_set(), and posix_cpu_timer_rearm(). When a non-leader exec() swaps the group leader, callers can observe a stale task pointer whose sighand has been cleared, without a mechanism to retry the lookup against the new leader.

Attack Vector

A local attacker with the ability to spawn a multi-threaded process, arm POSIX CPU timers, and perform exec() from a non-leader thread can race timer deletion against leader switching. Successful exploitation frees the k_itimer object while it remains enqueued in the signal timerqueue, resulting in a UAF that can be shaped into memory corruption for privilege escalation.

No verified public proof-of-concept code has been published. Refer to the upstream kernel commits for the authoritative fix and technical detail on the race window.

Detection Methods for CVE-2026-64560

Indicators of Compromise

  • Unexpected kernel oops, panics, or WARN_ON_ONCE messages referencing posix_cpu_timer_del, posix_cpu_timer_set, run_posix_cpu_timers, or timerqueue functions.
  • KASAN or slab debugging reports indicating use-after-free access to k_itimer structures.
  • Repeated crashes correlated with multi-threaded processes that call execve() from non-leader threads while managing CPU timers.

Detection Strategies

  • Enable CONFIG_KASAN on test kernels to surface UAF access patterns in posix-cpu-timers code paths.
  • Aggregate kernel dmesg output centrally and alert on stack traces containing posix_cpu_timer_* frames.
  • Audit workloads for processes that combine timer_create() with POSIX CPU clock IDs and frequent execve() calls from worker threads.

Monitoring Recommendations

  • Forward /var/log/kern.log and journald kernel messages to a centralized log platform and build detections for kernel warnings, oops signatures, and unexpected reboots.
  • Track kernel version inventory across the fleet and flag hosts running kernels lacking the referenced stable commits.
  • Correlate host crash telemetry with process execution telemetry to identify anomalous execve() bursts preceding kernel faults.

How to Mitigate CVE-2026-64560

Immediate Actions Required

  • Apply the upstream kernel patches referenced in the stable tree commits, or upgrade to a distribution kernel that includes the fix.
  • Prioritize patching multi-tenant systems, container hosts, and any environment where untrusted local code can execute.
  • Reboot systems after kernel package updates to ensure the patched kernel is active.

Patch Information

The fix introduces four coordinated changes: converting the p->sighand = NULL store in __exit_signal() to smp_store_release(), adding smp_acquire__after_ctrl_dep() on the !sighand path of lock_task_sighand(), adding a helper that retries the task lookup when sighand is NULL, and applying that helper across the three affected posix_cpu_timer_* functions. Authoritative commits are available on kernel.org: 12a891c7, 67aa823e, 6a7ecc25, 920f893f, ad1cafa1, cc35ddbc, d8bcb28a, and e74443f5.

Workarounds

  • Restrict local access on affected hosts. The vulnerability requires local execution, so limiting untrusted user shells reduces exposure.
  • Where feasible, constrain workloads with seccomp filters that limit timer_create() with CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID for untrusted processes.
  • Use containerization and user namespace restrictions to reduce the impact of a successful kernel exploit while patching is scheduled.
bash
# Verify kernel version and confirm patched build is running
uname -r

# Debian/Ubuntu: update and reboot
sudo apt update && sudo apt upgrade -y linux-image-$(uname -r | cut -d- -f3-)
sudo reboot

# RHEL/CentOS/Rocky: update and reboot
sudo dnf update -y kernel
sudo reboot

# Optional: seccomp-based restriction example (application-specific)
# Block timer_create for untrusted workers if not required
# See seccomp documentation for policy authoring

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.