Bug 2414726 (CVE-2025-40201)

Summary:	CVE-2025-40201 kernel: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	Keywords:	Security
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Linux kernel’s sys_prlimit64() implementation in kernel/sys.c. When a non-leader task (tsk) is passed in, the code calls get_task_struct(tsk) but then subsequently calls task_lock(tsk->group_leader), which may have already been freed if the task has exited or executed. In addition, ->group_leader may be changed via mt-exec, so do_prlimit() may take an incorrect lock or operate on a freed structure. A local attacker with the ability to call sys_prlimit64() on another task may trigger a race condition, potentially leading to a denial-of-service (kernel crash) situation.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-11-12 23:02:47 UTC

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.

Comment 1 Alexander B 2025-11-13 11:20:30 UTC

Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025111246-CVE-2025-40201-b8fe@gregkh/T