Executive brief
The Linux kernel contains a race condition in futex (fast userspace mutex) hash allocation that can occur when nested vfork processes concurrently attempt to set futex hash parameters. An attacker exploiting this could cause memory corruption when a freed hash table is accessed, leading to potential system instability or denial of service.
Technical details
The vulnerability is a use-after-free race condition in futex_hash_allocate() and the percpu counter allocation for mm->futex.phash.ref. When two tasks in the same memory space concurrently call prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS), both see the counter as NULL and each allocates its own percpu structure, but only the last store survives via simple assignment. The first-allocated counter becomes unreachable and its reference count is never updated, causing the associated private hash to be incorrectly freed while still in use. Subsequent access in futex_q_lock() then writes to freed memory. The fix uses atomic cmpxchg() to ensure only one counter is installed, and ensures the initial reference is taken before the store to prevent concurrent hash installation. The vulnerability affects nested vfork scenarios where the parent is released from its vfork suspension and races with grandchild processes.
Affected products
- Linux Linux kernel affected versions not specified
Timeline
- 2026-09-04: disclosed: Published in NVD