CVE-2026-80776 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix race in futex_pivot_pending() during private hash resize
A task performing a custom private hash resize can remain blocked in uninterruptible sleep indefinitely. The hung-task detector reports:
INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311
Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: hung_task: blocked tasks
futex_pivot_pending() allows the resize request to continue when either no replacement hash is pending (hash_new == NULL) or the current hash reference count has reached zero.
After the final-reference wake, another futex task can complete the pivot between the two observations:
T1 T2
futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcu_dereference(hash) /* new */ futex_ref_is_dead(fph) -> false schedule()
The pivot changes the state from hash_new != NULL with a dead current hash to hash_new == NULL with a live current hash. Because futex_pivot_pending() reads hash_new and hash without serialization, the resize task can observe hash_new in the pre-pivot state and hash in the post-pivot state, causing futex_pivot_pending() to return false even though the pivot has completed. The task then goes to sleep after the wakeup has already been consumed.
Serialize state reads in futex_pivot_pending() using futex_mm_phash::lock. This guarantees that futex_pivot_pending() observes hash_new and hash atomically, eliminating the race condition.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical concurrency flaw within the futex subsystem specifically affecting private hash table resizing operations. The vulnerability resides in the futex_pivot_pending function which is responsible for determining whether a pending hash resize operation has completed so that the requesting task can proceed or sleep appropriately. Under normal circumstances this mechanism ensures safe transitions between old and new hash tables during memory management updates. However due to insufficient synchronization when reading shared state variables the function exhibits a race condition that allows tasks to become permanently blocked in an uninterruptible sleep state indefinitely. This behavior triggers kernel hung-task detectors which report tasks blocked for extended periods potentially leading to system instability or panic conditions as observed in production environments where such hangs are treated as fatal errors requiring immediate intervention.
The technical root cause involves the lack of atomicity when accessing two critical pointers hash_new and hash within futex_pivot_pending without holding appropriate locks. During a private hash resize operation task T1 may allocate new memory for the replacement hash table while waiting on reference count changes to signal readiness. Meanwhile another concurrent thread or interrupt context can execute the actual pivot logic changing both pointer values from pointing to an obsolete dead hash structure with a pending new allocation to pointing exclusively to the newly allocated live hash structure with no pending operations remaining. Because these reads occur without serialization task T1 might observe hash_new as non-null indicating a pending operation while simultaneously observing that the current active hash has already been switched to the new version. This inconsistent view causes futex_pivot_pending to incorrectly conclude that the pivot is not yet complete and return false prompting the resizing task to enter an uninterruptible sleep state even though all necessary conditions for completion have technically been met elsewhere in the system.
The operational impact of this vulnerability manifests as severe performance degradation or total service unavailability depending on workload characteristics. Tasks involved in futex operations such as thread synchronization process creation and inter-process communication may become permanently stuck preventing normal application execution flow. In multi-threaded applications relying heavily on futexes for locking mechanisms the accumulation of blocked tasks can exhaust system resources including memory pools and scheduling queues leading to cascading failures across dependent services. The kernel panic triggered by hung-task detection further exacerbates reliability issues causing unexpected reboots or forced restarts that disrupt business continuity particularly in high-availability infrastructure where uptime is paramount.
This vulnerability aligns with CWE category 362 which covers concurrent execution using shared resources with improper synchronization mechanisms specifically highlighting race conditions arising from unsynchronized access to mutable state variables. From a threat modeling perspective the behavior resembles aspects of ATT&CK technique T1059 related to command and script interpreters although more accurately it represents an internal kernel logic error rather than external exploitation vector since direct remote code execution is not implied but denial-of-service through resource exhaustion remains possible via crafted workloads triggering repeated resize operations.
The resolution implemented by the Linux community involves introducing proper locking semantics into futex_pivot_pending using the existing futex_mm_phash lock structure to serialize access to both hash_new and hash pointers. By ensuring that these values are read atomically under a single critical section the function now correctly observes consistent states reflecting either pre-pivot or post-pivot conditions exclusively eliminating ambiguity in decision logic. This fix guarantees that resizing tasks accurately detect completion of pivot operations avoiding spurious sleeps while maintaining overall system stability during dynamic memory management activities associated with futex hash table expansions and contractions under heavy concurrent load scenarios typical in modern multi-core environments handling thousands of synchronized threads simultaneously.