Re: [PATCH] sched/autogroup: Fix task_group UAF during thread creation

[Daehyeon Ko <4ncienth@gmail.com>]

On Mon, Oct 26, 2026 at 12:57:07PM +0100, Peter Zijlstra wrote:
> I'm not sure this works; afaict this will result in a NULL deref
> instead.

Thanks for taking a look.

The NULL previous cfs_rq should be handled by the existing set_task_rq()
contract. __sched_fork() initializes p->se.cfs_rq to NULL, and the normal
sched_cgroup_fork() path reaches set_task_rq() through __set_task_cpu().
set_task_rq_fair() returns when prev is NULL, before
cfs_rq_last_update_time(prev), and set_task_rq() then installs the new
cfs_rq, parent, and depth.

> Can't we make ksys_setsid() more complicated instead? Have it create the
> autogroup in advance, move under the tasklist_lock and destroy on
> failure or something?

I don't think moving the autogroup move under tasklist_lock alone closes
the window, because sched_cgroup_fork() runs before copy_process() takes
tasklist_lock:

  clone(CLONE_THREAD)              setsid()
  -------------------              --------
  sched_cgroup_fork() -> old tg
                                    create new autogroup
                                    lock(tasklist_lock)
                                    move listed threads; child is absent
                                    unlock(tasklist_lock)
                                    drop old autogroup reference
  lock(tasklist_lock)
  publish child with old tg

The ordering trace hit this pre-publication sequence seven times. The
final revalidation is intended to cover precisely this interval.

Am I missing another ordering which excludes this interleaving?