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.
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Fri, 14 Nov 2025 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Thu, 13 Nov 2025 10:00:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Vendors & Products Linux
Linux linux Kernel

Wed, 12 Nov 2025 22:15:00 +0000

Type Values Removed Values Added
Description 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.
Title kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths
References

cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-11-12T21:56:34.063Z

Reserved: 2025-04-16T07:20:57.178Z

Link: CVE-2025-40201

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2025-11-12T22:15:47.283

Modified: 2025-11-14T16:42:30.503

Link: CVE-2025-40201

cve-icon Redhat

Severity : Moderate

Publid Date: 2025-11-12T00:00:00Z

Links: CVE-2025-40201 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2025-11-13T09:52:12Z