Answer in brief
CVE-2025-40201 records a Unknown severity vulnerability in kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <1bc0d9315ef5296abb2c9fd840336255850ded18 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <132f827e7bac7373e1522e89709d70b43cae5342 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <19b45c84bd9fd42fa97ff80c6350d604cb871c75 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <6796412decd2d8de8ec708213bbc958fab72f143 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <a15f37a40145c986cdf289a4b88390f35efdecc4 | 1bc0d9315ef5296abb2c9fd840336255850ded18, 132f827e7bac7373e1522e89709d70b43cae5342, 19b45c84bd9fd42fa97ff80c6350d604cb871c75, 6796412decd2d8de8ec708213bbc958fab72f143, a15f37a40145c986cdf289a4b88390f35efdecc4 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Nov 12, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2025-40201 records a Unknown severity vulnerability in kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <1bc0d9315ef5296abb2c9fd840336255850ded18 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <132f827e7bac7373e1522e89709d70b43cae5342 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <19b45c84bd9fd42fa97ff80c6350d604cb871c75 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <6796412decd2d8de8ec708213bbc958fab72f143 || >=18c91bb2d87268d23868bf13508f5bc9cf04e89a <a15f37a40145c986cdf289a4b88390f35efdecc4 | 1bc0d9315ef5296abb2c9fd840336255850ded18, 132f827e7bac7373e1522e89709d70b43cae5342, 19b45c84bd9fd42fa97ff80c6350d604cb871c75, 6796412decd2d8de8ec708213bbc958fab72f143, a15f37a40145c986cdf289a4b88390f35efdecc4 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Nov 12, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.