VulnerabilityPublished 4 Sep 2026Updated 30 Sep 2026

CVE-2026-80776: Linux kernel · futex: Fix race in futex_pivot_pending() during private hash resize

Affects Linux kernelSource GCVE Database

Not known to be exploited.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Medium

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.

Exploitation evidence

Disclosed: evidence found.
CVE published 4 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

ghsa-rqc7-j8jr-5jrx

What to do

Affected software

Product	Affected	Fixed in
Ubuntu 26.04 LTSlinux`pkg:deb/ubuntu/linux?arch=source&distro=resolute`Other threats	Affected 6.17.0-5.5 – 7.0.0-34.34 22 affected builds	Fixed in–
Ubuntu 26.04 LTSlinux-aws`pkg:deb/ubuntu/linux-aws?arch=source&distro=resolute`Other threats	Affected 6.17.0-1002.2 – 7.0.0-1013.13 14 affected builds	Fixed in–
Ubuntu 26.04 LTSlinux-azure`pkg:deb/ubuntu/linux-azure?arch=source&distro=resolute`Other threats	Affected 6.17.0-1003.3 – 7.0.0-1014.14 14 affected builds	Fixed in–
Ubuntu 26.04 LTSlinux-azure-fde`pkg:deb/ubuntu/linux-azure-fde?arch=source&distro=resolute`Other threats	Affected 7.0.0-1003.3 – 7.0.0-1013.13 8 affected builds	Fixed in–
Ubuntu 26.04 LTSlinux-gcp`pkg:deb/ubuntu/linux-gcp?arch=source&distro=resolute`Other threats	Affected 6.17.0-1002.2 – 7.0.0-1013.13 12 affected builds	Fixed in–
Ubuntu 26.04 LTSlinux-gke`pkg:deb/ubuntu/linux-gke?arch=source&distro=resolute`Other threats	Affected 7.0.0-1002.3 – 7.0.0-1007.8 5 affected builds	Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix has been implemented that serializes state reads in futex_pivot_pending() using futex_mm_phash::lock to eliminate the race condition. Users should apply the official Linux kernel update that includes this patch to resolve the issue. Patch status is not explicitly confirmed in the provided data; verify with the vendor or kernel maintainers for the latest remediation guidance.

Description

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.

Impact

Affected systems may experience tasks stuck indefinitely in uninterruptible sleep during futex private hash resize operations, which can trigger the kernel's hung-task detector and cause kernel panic. This results in system instability and potential denial of service. There is no indication of code execution or privilege escalation from the provided data.

Summary

The vulnerability in the Linux kernel futex subsystem involves a race condition in futex_pivot_pending() during private hash resize operations. When resizing the private hash, a task can observe inconsistent states of the hash pointers due to lack of serialization, causing it to miss wakeup events and remain blocked indefinitely in uninterruptible sleep. This can trigger the kernel's hung-task detector and lead to kernel panic. The root cause is that futex_pivot_pending() reads hash_new and hash without synchronization, allowing a task to see a pre-pivot state for hash_new and a post-pivot state for hash, resulting in a false negative for pending pivots. The patch serializes these reads using futex_mm_phash::lock to guarantee atomicity and prevent the race condition.

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 7 Sep 2026, 11:37 UTC

Technical details

References

Community reviews

Related threats