futex: Fix race in futex_pivot_pending() during private hash resize
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 pos
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.46, 7.1.11
- CVEs
- CVE-2026-80776
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 13:23 UTC · Revision 1
Source evidence
futex: Fix race in futex_pivot_pending() during private hash resize
core-osv · Original sourcePublished 4 Sept 2026, 15:12 UTC
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 pos
osv:CVE-2026-80776
Kernel
Fixed versions: 6.18.46, 7.1.11
Complete source record
{
"id": "bdcb5b42fe0dbcd5a39b542e956456cd15141b5f96f56f37d1a39c11f817e565",
"url": "https://osv.dev/vulnerability/CVE-2026-80776",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "futex: Fix race in futex_pivot_pending() during private hash resize",
"summary": "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 pos",
"evidence": "osv:CVE-2026-80776",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.46",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.11",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-80776",
"aliases": [
"CVE-2026-80776"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "bd54df5ea7cadac520e346d5f0fe5d58e635b6ba"
},
{
"fixed": "4a7e941ca29a608c6244cbd028d3599ecaef7207"
},
{
"fixed": "19b4be0717fa83265d66aea836b7022d898422cf"
},
{
"fixed": "8e7ff730dd96519a333d1570edf1c3fabb6d3629"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80776.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.16.0"
},
{
"fixed": "6.18.46"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.11"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80776.json"
}
}
],
"modified": "2026-10-28T02:30:28.802443015Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/19b4be0717fa83265d66aea836b7022d898422cf",
"https://git.kernel.org/stable/c/4a7e941ca29a608c6244cbd028d3599ecaef7207",
"https://git.kernel.org/stable/c/8e7ff730dd96519a333d1570edf1c3fabb6d3629",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80776.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-80776",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80776.json"
}
},
"related_cves": [
{
"value": "CVE-2026-80776",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 495823,
"published_at": "2026-09-04T15:12:48.314+00:00"
}