Bug 2492413 (CVE-2026-52973)

Summary: CVE-2026-52973 kernel: futex: Drop CLONE_THREAD requirement for private default hash alloc
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's futex subsystem. The need_futex_hash_allocate_default() function incorrectly relies on CLONE_THREAD semantics, which can lead to non-concurrency issues when memory allocations (mm->futex_ref pcpu allocations) are shared across CLONE_VM clones, excluding vfork(). This can result in a use-after-free vulnerability in futex_hash_put, a form of memory corruption. Such vulnerabilities can potentially lead to system instability or other security impacts.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-06-24 18:10:52 UTC
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.

Comment 9 errata-xmlrpc 2026-07-24 10:04:23 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:45114 https://access.redhat.com/errata/RHSA-2026:45114

Comment 11 errata-xmlrpc 2026-07-28 11:24:53 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:47040 https://access.redhat.com/errata/RHSA-2026:47040

Comment 12 errata-xmlrpc 2026-09-02 14:03:21 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:62642 https://access.redhat.com/errata/RHSA-2026:62642

Comment 13 errata-xmlrpc 2026-09-02 14:07:41 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:62640 https://access.redhat.com/errata/RHSA-2026:62640