CVE-2026-52973

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

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/1dcd36420af2da5bd59306dba9caf78e3d248b1d
• https://git.kernel.org/stable/c/974ac49a9a068b0591a59f65c63eb06579a13091
• https://git.kernel.org/stable/c/ee9dce44362b2d8132c32964656ab6dff7dfbc6a
• https://access.redhat.com/security/cve/CVE-2026-52973
• https://bugzilla.redhat.com/show_bug.cgi?id=2492413
• https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52973.json