CVE-2026-98788: futex: Fix private hash use-after-free on resize
In the Linux kernel, the following vulnerability has been resolved:
futex: Fix private hash use-after-free on resize
pollstatesynchronizercu(mm->futex.phash.batches) is used by futexrefdrop() 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.
futexpivothash() sets mmph->batches before it replaces mmph->hash:
scopedguard(rcu) { mmph->batches = getstatesynchronizercu(); rcuassignpointer(mmph->hash, new); }
The scopedguard(rcu) doesn't stop new grace periods from starting, and if one starts between those two assignments, futexrefdrop() 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 scopedguard(rcu) isn't needed, so let's drop that as well.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In __futex_pivot_hash(), assign the new hash with rcu_assign_pointer(mmph->hash, new) before setting mmph->batches = get_state_synchronize_rcu(); remove the unnecessary scoped_guard(rcu) wrapper.
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The race occurs while the kernel resizes a process's private futex hash and another reader still holds a pointer to the old hash. A new RCU grace period beginning between publication of the batch state and replacement of the hash pointer can allow the old hash to be freed too early.
How can I determine whether a kernel includes the fix?
Check whether the kernel source or its applied stable patches includes either referenced change: 5d5dc18b3a9ac011619b7d3af4514bf9e9b6a6af or f35e3b5784221654f9cdbd6222275a7fa203f6c3. The corrected ordering assigns the new hash pointer before updating the batch state, and removes the unnecessary RCU scoped guard.