CVE-2026-80776: futex: Fix race in futex_pivot_pending() during private hash resize
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix race in futexpivotpending() 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 futexhashallocate+0x3db/0x490 dosysprctl+0x6f5/0xbd0 dosyscall64+0xf9/0x530 entrySYSCALL64afterhwframe+0x77/0x7f
Kernel panic - not syncing: hungtask: blocked tasks
futexpivotpending() allows the resize request to continue when either no replacement hash is pending (hashnew == 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
futexhashallocate() waitvarevent(mm, ...) futexpivotpending(mm) hashnew != NULL futexhash() futexrefget(old) -> false futexpivothash(mm) hashnew = NULL futexpivothash(mm, new) rcuassignpointer(hash, new) fph = rcudereference(hash) / new / futexrefisdead(fph) -> false schedule()
The pivot changes the state from hashnew != NULL with a dead current hash to hashnew == NULL with a live current hash. Because futexpivotpending() reads hashnew and hash without serialization, the resize task can observe hashnew in the pre-pivot state and hash in the post-pivot state, causing futexpivotpending() 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 futexpivotpending() using futexmmphash::lock. This guarantees that futexpivotpending() observes hashnew and hash atomically, eliminating the race condition.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix that serializes futex state reads in futex_pivot_pending() by using futex_mm_phash::lock, eliminating the race during private hash resize that can lead to hung tasks/kernel panic.
Linux kernel futex_pivot_pending() Serialize state reads in futex_pivot_pending() using futex_mm_phash::lock = enabled
Event History
Frequently Asked Questions
Who is affected by this issue?
Systems running the Linux kernel are affected when a task performs a custom private futex hash resize. The reported failure is an indefinitely blocked task in uninterruptible sleep during that resize operation.
What is required to trigger the race?
The race requires concurrent futex activity while a custom private hash resize is pending. A second futex task must be able to complete the hash pivot after the resize path observes a pending replacement hash and before it acts on the old hash reference state.
How can administrators identify a system already experiencing this problem?
Look for hung-task reports showing a task blocked in futex_hash_allocate(), with a stack including schedule() and __do_sys_prctl(). The documented example identifies a futex-resizer task blocked for more than 10 seconds and may lead to a hung_task kernel panic.