Cloudanix VulnDB

CVE-2026-80776

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can make the system freeze or crash when certain internal synchronization operations run at the same time.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in futex_pivot_pending() allows a resize task to observe inconsistent hash state across a pivot, missing the wakeup and entering indefinite uninterruptible sleep that triggers hung-task detection and kernel panic.

Why it matters to the business

Linux systems performing custom private futex hash resizes can experience prolonged hangs or forced reboots, disrupting workloads and requiring manual intervention; low exploitability and absence from known campaigns limit immediate external risk but still affects stability for affected kernels.

How an attack unfolds

An attacker with local code execution triggers concurrent futex hash operations that interleave the pivot and resize checks, causing the allocating task to sleep forever after the wakeup is lost; no remote vector or named threat actors are associated.

How to fix it

Upgrade to a kernel containing the fix that serializes reads in futex_pivot_pending() with futex_mm_phash::lock; apply the stable backport for the running kernel version as soon as available.

How to confirm the fix worked

Confirm the patched kernel version is running, then exercise futex hash resize workloads while monitoring for hung-task reports; absence of indefinite blocks after the fix indicates exposure has been removed.

Typical attack path

  1. Obtain local execution on a Linux system running an affected kernel
  2. Trigger or wait for a private futex hash resize via prctl or related syscalls
  3. Race the pivot and reference-count observations to consume the wakeup
  4. Observe hung-task timeout and potential kernel panic

How to detect it

Search kernel logs for hung-task messages naming futex-resizer or similar tasks blocked in futex_hash_allocate; inspect for repeated schedule calls from __do_sys_prctl on systems performing hash resizes.

What your security team should do

  • Prioritize kernel updates on any system exposing futex resize paths
  • Monitor hung-task detector logs for futex-resizer or similar blocked tasks
  • Test patched kernels in staging before broad deployment
  • Review downstream package updates once distributions release fixed kernels

The record

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.

Affected packages

Ecosystem Package Introduced Fixed