# CVE-2026-64560: posix-cpu-timers: Prevent UAF caused by non-leader exec() race

> A race condition in Linux kernel posix-cpu-timers allows a use-after-free, potentially enabling local attackers to execute code or escalate privileges.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 29 Jul 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-94148, BELL-CVE-2026-64560, DEBIAN-CVE-2026-64560, GHSA-78ph-mc3q-52vv, ROOT-OS-DEBIAN-12-CVE-2026-64560, UBUNTU-CVE-2026-64560

## What is CVE-2026-64560?

CVE-2026-64560 is a high-severity use after free vulnerability in Linux, published on 29 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

posix-cpu-timers: Prevent UAF caused by non-leader exec() race

Wongi and Jungwoo decoded and reported a non-leader exec() related race
which can result in an UAF:

 sys_timer_delete()			exec()
   posix_cpu_timer_del()
   // Observes old leader
   p = pid_task(pid, pid_type);		de_thread()
   					  switch_leader();
					  release_task(old_leader)
					    __exit_signal(old_leader)
					      sighand = lock(old_leader, sighand);
					      posix_cpu_timers*_exit();
   sighand = lock_task_sighand(p)	      unhash_task(old_leader);
     sh = lock(p, sighand)	    	      old_leader->sighand = NULL;
					      unlock(sighand);
     (p->sighand == NULL)
	unlock(sh)
	return NULL;

   // Returns without action
   if(!sighand)
      return 0;
   free_posix_timer();

This is "harmless" unless the deleted timer was armed and enqueued in
p->signal because on exec() a TGID targeted timer is inherited.

As sys_timer_delete() freed the underlying posix timer object
run_posix_cpu_timers() or any timerqueue related add/delete operations on
other timers will access the freed object's timerqueue node, which results
in an UAF.

There is a similar problem vs. posix_cpu_timer_set(). For regular posix
timers it just transiently returns -ESRCH to user space, but for the use
case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is
allocated on the stack.

Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops
to expire.

While debating solutions Frederic pointed out another problem:

   posix_cpu_timer_del(tmr)
					__exit_signal(p)
					  posix_cpu_timers*_exit(p);
					  unhash_task(p);
					  p->sighand = NULL;
     sh = lock_task_sighand(p)
        sighand = p->sighand;
	if (!sighand)
	    return NULL;
	lock(sighand);

     if (!sh)
	WARN_ON_ONCE(timer_queued(tmr));

On weakly ordered architectures it is not guaranteed that
posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit()
when p->sighand is observed as NULL, which means the WARN() can be a false
positive.

Solve these issues by:

  1) Changing the store in __exit_signal() to smp_store_release().

  2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path
     of lock_task_sighand().

  3) Creating a helper function for looking up the task and locking sighand
     which does not return when sighand == NULL. Instead it retries the
     task lookup and only if that fails it gives up.

  4) Using that helper in the three affected functions.

#1/#2 ensures that the reader side which observes sighand == NULL also
observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()
and the ones in unhash_task().

#3 ensures that the above described non-leader exec() situation is handled
gracefully. When the task lookup returns the old leader, but sighand ==
NULL then it retries. In the non-leader exec() case the subsequent task
lookup will observe the new leader due to #1/#2. In normal exit() scenarios
the subsequent lookup fails.

When the task lookup fails, the function also checks whether the timer is
still enqueued and issues a warning if that's the case. Unfortunately there
is nothing which can be done about it, but as the task is already not
longer visible the timer should not be accessed anymore. This check also
requires memory ordering, which is not provided when the first lookup
fails. To achieve that the check is preceeded by a smp_rmb() which pairs
with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that
the stores in posix_cpu_timers*_exit() are visible.

The history of the non-leader exec() issue goes back to the early days of
posix CPU timers, which stored a pointer to the group leader task in the
timer. That obviously fails when a non-leader exec() switches the leader.
commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems
with mt exec") added a temporary workaround for that in 2010 which surv
---truncated---

Weakness: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)

## Which versions are affected by CVE-2026-64560?


## How do I fix CVE-2026-64560?

Apply the vendor's patch.

## Is CVE-2026-64560 being exploited?

There is no known exploitation of CVE-2026-64560 in the wild and no public exploit code.

Public exploit code:

- https://github.com/villager1314/CVE-2026-64560-Analysis (github_poc): https://github.com/villager1314/CVE-2026-64560-Analysis
- 一加 15T（PLZ110）临时 root + KernelSU per-boot 接管：CVE-2026-64560 移植，不写分区、重启即失效。内核 6.12.69-android16-6-g242e1a07f878。 (github_poc): https://github.com/feiguang-ai/plz110-6.12.69-cve-2026-64560-ksu
- CVE-2026-64560 staged security research package (github_poc): https://github.com/Feng1586/CVE-2026-64560-public
- Device-bound CVE-2026-64560 adaptation for Xiaomi 15 dada OS4.0.0.8 (github_poc): https://github.com/quyicheng03-boop/xiaomi15-dada-cve-2026-64560
- https://github.com/a23bc/op13-cve-2026-64560 (github_poc): https://github.com/a23bc/op13-cve-2026-64560
- OnePlus 16 (PYB110) jailbreak: CVE-2026-64560 + CVE-2026-98260 + KernelSU / KernelSU Next / BakaSU / SukiSU Ultra LKM (github_poc): https://github.com/Yunnijian/OnePlus16-Jailbreak

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-64560 and fix it if it is affected.

What it is: CVE-2026-64560 is a high-severity use after free vulnerability in Linux, published on 29 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-64560 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-64560/ (Markdown: https://insights.sbomify.com/CVE-2026-64560/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-64560
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-64560
- OSV: https://osv.dev/vulnerability/CVE-2026-64560

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-64560/
Summaries are generated and may contain mistakes; the official description above is the record.