Re: [tip: timers/urgent] posix-cpu-timers: Prevent UAF caused by non-leader exec() race

[Frederic Weisbecker]

Le Sun, Jul 05, 2026 at 09:46:36AM -0000, tip-bot2 for Thomas Gleixner a écrit :
> The following commit has been merged into the timers/urgent branch of tip:
> 
> Commit-ID:     920f893f735e92ba3a1cd9256899a186b161928d
> Gitweb:        https://git.kernel.org/tip/920f893f735e92ba3a1cd9256899a186b161928d
> Author:        Thomas Gleixner <tglx@xxxxxxxxxx>
> AuthorDate:    Fri, 03 Jul 2026 12:02:38 +02:00
> Committer:     Thomas Gleixner <tglx@xxxxxxxxxx>
> CommitterDate: Sun, 05 Jul 2026 11:44:06 +02:00
> 
> 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.

do_cpu_nanosleep() only targets current and since it's on the stack, no
other task can access it. And the current task can't be exiting/exec'ing
while calling posix_cpu_timer_set() on that stack timer.

> + * That's problematic for several functions:
> + *
> + *  - posix_cpu_timer_del(): If the timer is still enqueued on the task the
> + *    underlying k_itimer will be freed which results in a UAF in
> + *    run_posix_cpu_timers() or on timerqueue related add/delete operations.
> + *    If the timer is not enqueued, the failure is harmless
> + *
> + *  - posix_cpu_timer_set(): Independent of the enqueued state that results in a
> + *    transient failure which is user space visible (-ESRCH) for regular posix
> + *    timers. But for the use case in do_cpu_nanosleep() it's the same UAF
> + *    problem just that the timer is allocated on the stack.

Ditto.

Other than that:

Reviewed-by: Frederic Weisbecker <frederic@xxxxxxxxxx>

-- 
Frederic Weisbecker
SUSE Labs