Live › vulnerability › CVE-2026-98788
Go to dashboardWhen the kernel resizes a process's private futex hash table, a race can let the old table be freed while a reader still holds a pointer to it. The sources do not say what an attacker can do with the freed memory beyond the use-after-free itself.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix private hash use-after-free on resize
poll_state_synchronize_rcu(mm->futex.phash.batches) is used by futex_ref_drop() to check that a grace period has passed since the current hash was published. This relies on batches referencing a grace period which started after the hash pointer was assigned.
__futex_pivot_hash() sets mmph->batches before it replaces mmph->hash:
scoped_guard(rcu) {
mmph->batches = get_state_synchronize_rcu();
rcu_assign_pointer(mmph->hash, new);
}
The scoped_guard(rcu) doesn't stop new grace periods from starting, and if one starts between those two assignments, futex_ref_drop() can move forward while a reader still holds a pointer to the old hash.
Fix things by setting mmph->batches after assigning mmph->hash. The scoped_guard(rcu) isn't needed, so let's drop that as well.
This page as .md · .json · in your agent: get_signal("CVE-2026-98788")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.