CVE-2026-98788 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel futex subsystem manages fast user-space locking primitives and relies heavily on Read-Copy-Update (RCU) mechanisms to ensure safe concurrent access to shared data structures without the overhead of traditional locks. A critical race condition was identified within the private hash table resizing logic, specifically involving the sequence used to update the hash pointer and synchronize grace periods. The vulnerability stems from an incorrect ordering in __futex_pivot_hash(), where the code updates the batches state variable before assigning the new hash pointer via RCU assignment primitives. This sequencing flaw creates a window of exposure during which the system is vulnerable to use-after-free conditions, undermining the memory safety guarantees that RCU is designed to provide.
The core technical flaw lies in the interaction between get_state_synchronize_rcu() and rcu_assign_pointer(). The function poll_state_synchronize_rcu(), invoked by futex_ref_drop(), checks whether a sufficient grace period has elapsed since the current hash was published, relying on the batches variable to track when that publication occurred. However, because __futex_pivot_hash() sets mmph->batches before replacing mmph->hash with the new pointer, any RCU grace period that begins between these two assignments is not properly accounted for in the synchronization check. Consequently, futex_ref_drop() may determine that a grace period has passed and proceed to free or reuse memory associated with the old hash structure, even though active readers might still be holding references to that old hash pointer. This results in a use-after-free vulnerability where kernel memory is accessed after it has been freed, potentially leading to data corruption or arbitrary code execution if an attacker can control the contents of the reused memory.
From a classification perspective, this issue aligns with CWE-416: Use After Free, as the root cause involves accessing memory that has already been deallocated due to improper synchronization timing. In terms of the MITRE ATT&CK framework for Linux systems, this vulnerability facilitates techniques related to privilege escalation or denial of service through kernel exploitation. The lack of proper ordering in RCU updates allows an attacker with local access to potentially trigger race conditions during hash table resizing operations, which are common under high-concurrency workloads. This type of flaw is particularly dangerous because it occurs within the kernel space, bypassing user-space security boundaries and affecting system stability and integrity directly.
The operational impact of this vulnerability includes potential kernel panics, data corruption in futex-related structures, and possible privilege escalation for local attackers who can trigger concurrent futex operations during hash resizing events. Since futexes are widely used by many applications for synchronization, the attack surface is broad, affecting any process that interacts with shared memory locks on vulnerable systems. The severity is heightened by the fact that RCU bugs often manifest intermittently under specific timing conditions, making them difficult to reproduce and diagnose in standard testing environments without specialized fuzzing or stress-testing tools designed to trigger race conditions.
To mitigate this vulnerability, it is essential to apply the kernel patch that corrects the ordering of operations within __futex_pivot_hash(). The fix involves moving the assignment of mmph->batches to occur after rcu_assign_pointer(mmph->hash, new), ensuring that any grace period starting during the update process correctly includes the publication of the new hash pointer. Additionally, removing the unnecessary scoped_guard(rcu) block simplifies the code and reduces potential points for future synchronization errors. System administrators should ensure their Linux kernels are updated to versions containing this fix. For developers integrating futex functionality or maintaining custom kernel modules, it is crucial to adhere strictly to RCU usage guidelines, ensuring that state updates precede pointer publications when relying on grace period checks for memory reclamation safety. Regular security audits and static analysis tools configured to detect improper RCU ordering can help prevent similar issues in future development cycles.