PT-2026-65857 · Linux · Linux
CVE-2026-64560
·
Published
2026-07-29
·
Updated
2026-07-29
CVSS v3.1
7.8
High
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
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:
-
Changing the store in exit signal() to smp store release().
-
Adding a smp acquire after ctrl dep() into the !sighand path of lock task sighand().
-
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.
-
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---
Fix
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux