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


Severity

Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.03% (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 Learn

Learn about Race Condition vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-AMZN2023-KERNEL612LIBBPFDEBUGINFO-14432125
  • 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-libbpf-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-libbpf-debuginfo package and not the kernel6.12-libbpf-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