Bug 2555186 (CVE-2026-98788) - CVE-2026-98788 kernel: kernel: Privilege escalation via use-after-free during futex hash resizing
Summary: CVE-2026-98788 kernel: kernel: Privilege escalation via use-after-free during...
Keywords:
Status: NEW
Alias: CVE-2026-98788
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-18 15:59 UTC by OSIDB Bzimport
Modified: 2026-10-21 14:30 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-18 15:59:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.