Race Condition Affecting kernel6.12-tools-debuginfo package, versions <1:6.12.55-74.119.amzn2023


Severity

Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.18% (9th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-KERNEL612TOOLSDEBUGINFO-14432103
  • published17 Dec 2025
  • disclosed12 Nov 2025

Introduced: 12 Nov 2025

CVE-2025-40201  (opens in a new tab)
CWE-362  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 kernel6.12-tools-debuginfo to version 1:6.12.55-74.119.amzn2023 or higher.
This issue was patched in ALAS2023-2025-1316.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel6.12-tools-debuginfo package and not the kernel6.12-tools-debuginfo package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1