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

CVE-2026-80776 Overview

CVE-2026-80776 is a race condition in the Linux kernel's fast userspace mutex (futex) subsystem. The flaw resides in futex_pivot_pending() and triggers during a custom private hash resize operation. A task requesting the resize can remain blocked in uninterruptible sleep (state D) indefinitely, causing the hung-task detector to fire a kernel panic when configured to do so.

The race stems from unserialized reads of hash_new and hash in futex_pivot_pending(). Under concurrent pivot activity, the resize task observes inconsistent state and misses the wakeup that would allow it to proceed.

Critical Impact
A local unprivileged task using prctl() to resize its private futex hash can deadlock and trigger a hung-task kernel panic, producing a denial-of-service condition on affected Linux systems.

Affected Products

Linux kernel versions containing the private futex hash resize feature and the vulnerable futex_pivot_pending() implementation
Distributions shipping stable kernels prior to the upstream fix commits
Systems where users can invoke prctl() to trigger custom futex hash resizes

Discovery Timeline

2026-09-04 - CVE-2026-80776 published to the National Vulnerability Database (NVD)
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80776

Vulnerability Analysis

The Linux futex subsystem supports per-process private hash tables to reduce contention. When a task requests a resize via prctl(), the kernel path futex_hash_allocate() calls wait_var_event() and relies on futex_pivot_pending() to determine whether the pivot to a new hash has completed.

futex_pivot_pending() returns true when either no replacement hash is pending (hash_new == NULL) or the current hash reference count has dropped to zero. Both conditions are checked by reading hash_new and hash without holding a lock, so the two reads are not atomic with respect to a concurrent pivot.

Between the two reads, another futex task can complete the pivot: futex_pivot_hash() clears hash_new and __futex_pivot_hash() publishes the new hash via rcu_assign_pointer(). The waiting task then observes hash_new in the pre-pivot state and hash in the post-pivot state, so futex_ref_is_dead() returns false and futex_pivot_pending() returns false. The task calls schedule() after its wakeup has already been consumed and never wakes again.

Root Cause

The root cause is a race condition [CWE-362] created by non-atomic reads of two related pieces of state (hash_new and the current hash pointer) in futex_pivot_pending(). Because the read pair is not serialized against the pivot writer, the checker can observe a mixed pre-/post-pivot snapshot that no consistent point in time ever exhibited.

Attack Vector

Exploitation requires local execution of a task that can call prctl() to drive a custom private futex hash resize while other threads in the same address space exercise futex operations that trigger the pivot. No elevated privileges are required, and no network access is involved. Successful triggering leaves the resize task in uninterruptible sleep. If hung_task_panic is enabled, the kernel panics; otherwise the task and any resources it holds are stuck until reboot.

Because no verified proof-of-concept has been published, the vulnerability is described in prose only. See the upstream commits linked below for the exact fix.

Detection Methods for CVE-2026-80776

Indicators of Compromise

Kernel log entries reporting INFO: task <name>:<pid> blocked for more than N seconds with a call trace containing futex_hash_allocate and __do_sys_prctl
Tasks in uninterruptible sleep state D with stacks pointing into futex_pivot_pending or futex_hash_allocate
Kernel panic messages of the form Kernel panic - not syncing: hung_task: blocked tasks on systems with kernel.hung_task_panic=1

Detection Strategies

Parse dmesg and journald output for hung-task warnings referencing futex hash allocation paths
Alert on unexpected kernel panics whose oops output references futex_hash_allocate or futex_pivot_pending
Inventory running kernel versions and flag hosts running builds that predate the fix commits 19b4be0, 4a7e941, and 8e7ff73

Monitoring Recommendations

Ship kernel logs to a centralized log platform and create rules that match on hung_task combined with futex_ symbols
Track host availability and unplanned reboots on Linux fleets, correlating with pre-panic hung-task warnings
Monitor workloads that make heavy use of prctl(PR_FUTEX_HASH, ...) for stalls or thread-count anomalies

How to Mitigate CVE-2026-80776

Immediate Actions Required

Apply the upstream stable kernel updates that include commits 19b4be0, 4a7e941, and 8e7ff73
Track your distribution's security advisories and deploy the vendor-provided kernel package as soon as it becomes available
Reboot affected hosts after patching so the fixed kernel is loaded

Patch Information

The fix serializes state reads inside futex_pivot_pending() using futex_mm_phash::lock, ensuring that hash_new and hash are observed atomically and eliminating the pre-/post-pivot mixed snapshot. The change is committed upstream in the Linux stable tree via commit 19b4be0, commit 4a7e941, and commit 8e7ff73.

Workarounds

Avoid application patterns that call prctl() to trigger custom private futex hash resizes on unpatched kernels
Consider setting kernel.hung_task_panic=0 on non-production systems to prevent a panic while patching is scheduled, accepting that stuck tasks will still consume resources
Restrict untrusted local workloads on shared multi-tenant hosts until the fixed kernel is deployed

bash

# Verify the running kernel and confirm the fix is present after patching
uname -r

# Check for prior hung-task events referencing the futex resize path
journalctl -k --grep 'hung_task|futex_hash_allocate|futex_pivot_pending'

# Optionally reduce panic-on-hang while planning the patch window (non-production)
sysctl -w kernel.hung_task_panic=0