]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64...
authorOleg Nesterov <oleg@redhat.com>
Mon, 15 Sep 2025 12:09:17 +0000 (14:09 +0200)
committerAndrew Morton <akpm@linux-foundation.org>
Tue, 23 Sep 2025 03:10:59 +0000 (20:10 -0700)
commita15f37a40145c986cdf289a4b88390f35efdecc4
tree32d31a54fe73bfe72fc7e82d4393d94045a79e05
parent39f17c707454290900b608ee5a200b5db9245626
kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths

The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit()
path is very broken.

sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct
itself. If tsk != current and tsk is not a leader, this process can exit/exec
and task_lock(tsk->group_leader) may use the already freed task_struct.

Another problem is that sys_prlimit64() can race with mt-exec which changes
->group_leader. In this case do_prlimit() may take the wrong lock, or (worse)
->group_leader may change between task_lock() and task_unlock().

Change sys_prlimit64() to take tasklist_lock when necessary. This is not
nice, but I don't see a better fix for -stable.

Link: https://lkml.kernel.org/r/20250915120917.GA27702@redhat.com
Fixes: 18c91bb2d872 ("prlimit: do not grab the tasklist_lock")
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Mateusz Guzik <mjguzik@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
kernel/sys.c