UBUNTU-CVE-2026-80776: Race Condition

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.