Use After Free Affecting kernel-debug-uki-virt package, versions <0:6.12.0-211.39.1.el10_2


Severity

Recommended
high

Based on Rocky Linux security rating.

Threat Intelligence

EPSS
0.14% (4th 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-ROCKY10-KERNELDEBUGUKIVIRT-18343139
  • published28 Jul 2026
  • disclosed24 Jun 2026

Introduced: 24 Jun 2026

CVE-2026-52973  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade Rocky-Linux:10 kernel-debug-uki-virt to version 0:6.12.0-211.39.1.el10_2 or higher.
This issue was patched in RLSA-2026:45114.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-debug-uki-virt package and not the kernel-debug-uki-virt package as distributed by Rocky-Linux. See How to fix? for Rocky-Linux:10 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

futex: Drop CLONE_THREAD requirement for private default hash alloc

Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie:

BUG: KASAN: slab-use-after-free in futex_hash_put

... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at.

Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM.

CVSS Base Scores

version 3.1