CVE-2026-80778 in Linux
Summary
by MITRE • 09/04/2026
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 ]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel futex subsystem manages fast userspace mutexes, providing an efficient mechanism for synchronization between threads within the same process or across processes when using shared memory. A critical flaw exists in how private futex priority inheritance (PI) operations handle cross-address space scenarios. Specifically, a private futex key borrows the memory descriptor of the waiter thread without incrementing the mm_users reference count to ensure its longevity. The function attach_to_pi_owner() incorrectly accepts an owner from a different address space and proceeds to copy the private key into that owner's PI state structure. This logic error creates a dangerous race condition where the kernel assumes ownership validity based on incorrect assumptions about memory management lifecycle.
The operational impact of this vulnerability manifests during process termination sequences. When the erroneous owner process exits, exit_pi_state_list() attempts to locate the corresponding hash bucket using the saved private key and acquires a reference to the waiter's private futex hash. If the last user of the waiter's address space exits concurrently with this cleanup operation, futex_hash_free() may free the memory associated with that hash while the exiting owner process still holds a pointer to it and attempts to access its bucket. This results in a use-after-free condition, allowing for potential kernel memory corruption or arbitrary code execution if an attacker can control the timing of these concurrent exits and manipulate the freed memory contents before they are reallocated for other purposes.
This vulnerability is classified under CWE-416, Use After Free, as it involves accessing memory that has been deallocated due to improper reference counting and validation logic. In terms of attack vectors, this aligns with ATT&CK technique T1059, Command and Scripting Interpreter, if leveraged for privilege escalation or lateral movement within a compromised system by exploiting kernel instability to gain higher privileges. The flaw highlights the complexity of managing shared resources in concurrent environments where memory lifecycle management must be strictly synchronized with object state transitions.
To mitigate this vulnerability, developers have implemented a validation check within attach_to_pi_owner() that ensures private futex owners and waiters reside in the same address space. This check is performed while holding the owner's pi_lock to serialize against concurrent PI-state exit cleanup operations, ensuring atomicity and preventing race conditions during state transitions. System administrators should apply kernel updates provided by their distribution vendors immediately to patch this issue. Additionally, organizations running custom kernels must backport these changes to maintain security posture. Regular auditing of futex usage in applications can help identify potential misuse patterns that might exacerbate such vulnerabilities under high-concurrency workloads.