Look up another CVE · open CVE-2026-52973 in the interactive tracker
CVE-2026-52973
futex: Drop CLONE_THREAD requirement for private default hash alloc
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem kernel. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-52973 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/fork.c
- What this is
- EXEC & BINFMT API, ELFMAINTAINERS section matched on kernel/fork.c · linux-mm@kvack.org · Supported
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS Debian linux-config packages
Signals
- Published
- 2026-06-24 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- kernel
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.17 | 6.18.33 | 1dcd36420af2 |
| 6.17 | 7.0.10 | 974ac49a9a06 |
| 6.17 | 7.1 | ee9dce44362b |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable path is reached through local `clone`/`clone3`, `prctl(PR_FUTEX_HASH, ...)`, and futex syscalls on user memory. It is not reachable directly over a network or adjacent/physical interface.
- AC:LAttack complexity, low
- The race is attacker-controlled: an unprivileged process can create multiple `CLONE_VM` non-`CLONE_THREAD` siblings and issue concurrent private futex hash operations. The public report demonstrates a reproducible unprivileged KASAN UAF using attacker-controlled timing aids.
- PR:LPrivileges required, low
- The trigger uses ordinary unprivileged local syscalls and the report reproduced it as UID 1000 without capabilities. No real root or init-namespace administrative privilege is required.
- UI:NUser interaction, none
- No victim action is needed after the attacker can execute local code. The attacker controls the clone, prctl, userfaultfd, and futex operations.
- S:UScope, unchanged
- The corruption occurs within the Linux kernel due to local syscall handling and affects the same kernel security authority. There is no hypervisor, IOMMU, or separate-scope boundary crossing.
- C:HConfidentiality impact, high
- This is a kernel use-after-free of a live `struct futex_private_hash`/bucket array, and UAF memory corruption can reasonably be leveraged for kernel memory disclosure. When uncertain, the higher-severity impact is appropriate.
- I:HIntegrity impact, high
- The UAF leaves futex code operating on freed and potentially attacker-reclaimed kernel heap memory, which can plausibly provide write/control-flow primitives. Kernel UAF memory corruption is scored as high integrity impact.
- A:HAvailability impact, high
- The reported impact includes a KASAN slab-use-after-free in `futex_hash_put()` and can crash/oops the kernel. A repeatable local kernel crash is high availability impact.