CVE-2026-80778: futex/pi: Reject cross-mm private futex owners
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 mmusers reference. Nevertheless, attachtopiowner() currently accepts an owner from a different address space and copies the private key into the owner's PI state.
When that owner exits, exitpistatelist() 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, futexhashfree() frees the hash while the owner still uses its bucket and reference.
Prevent this by validating in attachtopiowner() that, for private futexes, the owner mm and waiter mm are the same. Perform the check with the owner's pilock held and after validating owner::futex::state to serialize against a concurrent PI-state exit cleanup.
[ tglx: Amended comment ]
Affected Software
Event History
Frequently Asked Questions
Which futex operations are implicated?
The issue is limited to private futexes using priority-inheritance owner state. The problematic condition occurs when the futex owner and waiter belong to different memory address spaces.
What timing is required for the unsafe state to occur?
The owner must exit while its saved PI state still references the waiter's private futex hash, concurrently with the last user of the waiter's memory address space exiting. This can allow the futex hash to be freed while the owner still uses its bucket and reference.
Does the fix change handling of shared futexes?
The described validation applies specifically to private futexes. The provided information does not identify shared futexes as affected.