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.

• https://git.kernel.org/stable/c/19b4be0717fa83265d66aea836b7022d898422cf
• https://git.kernel.org/stable/c/4a7e941ca29a608c6244cbd028d3599ecaef7207
• https://git.kernel.org/stable/c/8e7ff730dd96519a333d1570edf1c3fabb6d3629

Published

Sep 4, 2026

Last Modified

Sep 4, 2026

Status

Received

• How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
• Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
• PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
• AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.

• CVE-2026-80770In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80771In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80772In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80773In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80774In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80775In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80777In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80778In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80779In the Linux kernel, the following vulnerability has been re…
• CVE-2026-8078Stored cross-site scripting in the global settings change lo…4.8
• CVE-2026-80780In the Linux kernel, the following vulnerability has been re…
• CVE-2026-80781In the Linux kernel, the following vulnerability has been re…