FlawAtlas
Search the atlas
CVE-2025-40201 Not scored

kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths

In the Linux kernel, the following vulnerability has been resolved: 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.

Exploit probability 0.2%
Published November 12, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown
Linux Kernel

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2025:20172-1
related SUSE-SU-2026:0962-1
related SUSE-SU-2026:1081-1
related SUSE-SU-2026:20012-1
related SUSE-SU-2026:20015-1
related SUSE-SU-2026:20021-1
related SUSE-SU-2026:21114-1
related SUSE-SU-2026:21123-1
related SUSE-SU-2026:21255-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2025-40201

In the Linux kernel, the following vulnerability has been resolved: 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.

View original source

05 / REFERENCES

Further evidence