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

[Tejun Heo]

Hello, Peter.

On Tue, Nov 03, 2026 at 12:45:57PM +0100, Peter Zijlstra wrote:
> Now, using cgroup_post_fork() seems weird (also, I'm not sure if this
> calls cgroup_subsys::fork for *all* controllers, or only the enabled
> ones).

It calls ->fork for every built-in controller that has one, whether or
not it's bound to a hierarchy or disabled with cgroup_disable=.

> But we can easily move this into sched_post_fork(); all we really need
> to ensure is this happens before scx_post_fork(), right?

Yeah, that works. AFAICS there's no ordering requirement against
scx_post_fork() though. sched_move_task(p, true) skips
scx_cgroup_move_task(), so the autogroup move doesn't invoke any sched_ext
op. tg_cgrp() maps both root_task_group and autogroup task_groups to the
root cgroup, so sched_ext sees the same cgroup either way. What matters is
that it runs after the task is on the thread list and before
wake_up_new_task().

> +	if (READ_ONCE(sysctl_sched_autogroup_enabled) &&
> +	    task_wants_autogroup(p, p->sched_task_group))
> +		sched_move_task(p, true);

The p->sched_task_group read races with setsid() and cgroup migration.
Maybe READ_ONCE()?

Separately, there's a pre-existing misplacement. If setsid() lands after
the new thread is on the thread list but before cgroup_post_fork() links
it to its css_set, sched_change_group() sees init_css_set and puts the
thread in the autogroup, or in root_task_group with autogroup disabled,
even when its cgroup isn't root, and it stays there. I think this should
be fixed from the setsid() side.

Thanks.

--
tejun