CVE-2026-80776

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.