CVE-2026-80775: Linux Kernel Futex Race Condition Vulnerability

CVE-2026-80775 Overview

CVE-2026-80775 is a race condition in the Linux kernel futex subsystem. The flaw affects the initial allocation of mm->futex.phash.ref, which futex_hash_allocate() performs without locking. Nested vfork() calls followed by a SIGKILL on a grandchild can release the parent while it shares memory with another task. When both concurrently invoke prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS), each observes a NULL reference counter and installs its own percpu counter. Only the last store persists, leaking references and eventually causing a use-after-free when futex_q_lock() writes into freed memory belonging to a private hash.

Critical Impact
Local unprivileged tasks sharing an mm through nested vfork() can trigger kernel memory corruption via a use-after-free in the futex private hash.

Affected Products

Linux kernel versions containing commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()")
Linux kernel versions containing commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc")
Stable kernel branches prior to the fix commits referenced in the kernel.org advisory

Discovery Timeline

2026-09-04 - CVE-2026-80775 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80775

Vulnerability Analysis

The futex private hash implementation stores a percpu reference counter at mm->futex.phash.ref. The prior assumption held that futex_hash_allocate() runs when the process has a single thread. Commit ee9dce44362b widened need_futex_hash_allocate_default() to cover any CLONE_VM clone but excluded vfork because the parent is suspended during a normal vfork.

That assumption breaks when vfork is nested. A vfork child that calls vfork again and is then terminated with SIGKILL releases the original parent from its vfork wait. The parent and the grandchild then execute concurrently within the same mm, and neither has traversed futex_hash_allocate_default().

Root Cause

The allocation of mm->futex.phash.ref was performed with a plain store rather than an atomic compare-and-swap. Two tasks racing through prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) each read NULL and each install a distinct percpu counter. The counter written first is overwritten and becomes unreachable from the mm, so references acquired against it are invisible to __futex_ref_atomic_end().

Attack Vector

A local task exploits the race by nesting vfork() and terminating the grandchild with SIGKILL to force concurrent execution against the shared mm. Both surviving tasks then invoke the PR_FUTEX_HASH_SET_SLOTS prctl. The private hash with orphaned references is later considered dead and freed, while another task still holds a bucket. When that task calls futex_q_lock(), it writes into freed kernel memory, producing a use-after-free ([CWE-416]) that can corrupt kernel state.

No public exploit code has been published. See the upstream commits (86d12b3, bde02380, c4b4972d, ff252ed4) for the code change.

Detection Methods for CVE-2026-80775

Indicators of Compromise

Unexpected kernel oops or panic messages referencing futex_q_lock, __futex_ref_atomic_end, or futex_hash_allocate.
KASAN reports flagging use-after-free access within the futex subsystem.
Processes issuing repeated prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) calls in combination with nested vfork() syscall patterns.

Detection Strategies

Enable Kernel Address Sanitizer (KASAN) in test and staging kernels to catch the use-after-free during execution.
Audit workloads that legitimately call the PR_FUTEX_HASH prctl and flag callers that combine it with vfork().
Correlate kernel crash telemetry with process ancestry to surface nested vfork patterns preceding faults in the futex code path.

Monitoring Recommendations

Ship kernel ring buffer output (dmesg, journald) to a central log store and alert on futex-related backtraces.
Monitor for unexpected process termination followed by parent-side kernel warnings originating from the same mm.
Track deployment status of the kernel patch across the fleet to identify hosts still exposed to the race.

How to Mitigate CVE-2026-80775

Immediate Actions Required

Inventory Linux hosts running kernels that include commits d9b05321e21e and ee9dce44362b but lack the fix.
Apply the stable kernel update containing the cmpxchg()-based fix on all affected systems and reboot.
Restrict execution of untrusted local code on multi-tenant hosts until the patched kernel is deployed.

Patch Information

The fix stores mm->futex.phash.ref once using cmpxchg() and lets the losing task free_percpu() its own counter. The initial reference is taken before the store to prevent another task from installing a private hash while the counter is still zero. The change is available in the following upstream commits: 86d12b3, bde02380, c4b4972d, and ff252ed4.

Workarounds

No supported configuration flag disables the futex private hash. Patching is the only reliable remediation.
On systems that cannot be immediately patched, minimize local attack surface by removing untrusted user shells and container runtimes with local exec privileges.
Use distribution-provided live kernel patching (kpatch, kGraft, Ksplice) where available to close the window before a full reboot.

bash

# Verify kernel version and confirm patch level
uname -r

# Debian/Ubuntu: apply latest kernel updates
sudo apt-get update && sudo apt-get install --only-upgrade linux-image-$(uname -r | cut -d- -f2-)
sudo reboot

# RHEL/CentOS/Fedora
sudo dnf update kernel && sudo reboot