HIGH Introduced in 6.16
futex PiOwner UAF
CVE-2026-80778
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
01Description
In the Linux kernel, the following vulnerability has been resolved: futex/pi: Reject cross-mm private futex owners A private futex key borrows the waiter's mm without taking an mm_users reference. Nevertheless, attach_to_pi_owner() currently accepts an owner from a different address space and copies the private key into the owner's PI state. When that owner exits, exit_pi_state_list() uses the saved key to find the hash bucket and acquires a reference to the waiter's private hash. If the last user of the waiter's mm exits concurrently, futex_hash_free() frees the hash while the owner still uses its bucket and reference. Prevent this by validating in attach_to_pi_owner() that, for private futexes, the owner mm and waiter mm are the same. Perform the check with the owner's pi_lock held and after validating owner::futex::state to serialize against a concurrent PI-state exit cleanup. [ tglx: Amended comment ]
02KernelScan AI Analysis
Risk summary
Any local unprivileged process can trigger a use-after-free in the futex PI subsystem by arranging a private futex whose owner task lives in a different address space. The race window between the owner's exit cleanup and the waiter's mm teardown allows freed hash memory to be accessed, leading to potential arbitrary kernel read/write or a crash. Systems running kernels 6.16 and later with the private futex hash feature are affected.
Vulnerability analysis
A private futex key stores a pointer to the waiting task's address space without holding a reference count on it. The code that attaches a priority-inheritance owner to a futex accepted an owner task from a different address space and copied that borrowed key into the owner's state. When the owner later exits, its cleanup path uses the saved key to look up the waiter's private hash bucket and take a reference to it; if the last user of the waiter's address space exits concurrently, the private hash is freed while the owner is still traversing it, producing a use-after-free. The fix adds a validation in the owner-attach path that rejects private futex owners whose address space differs from the waiter's, performed under appropriate locking to serialize against concurrent cleanup. The vulnerable path is reached through the standard futex syscall by any local process, though exploitation requires winning a race between two exiting tasks.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 6.16 | 6.18.47 | 2b92e5562653 |
| 7.1 | 6.16 | 7.1.11 | f7fb3e077526 |
| mainline | 6.16 | 7.3-rc1 | 59b3732f95dd |
| 7.2 | 6.16 | 7.2.1 | 43b148d796aa |