CVE-2026-80777 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
futex/pi: Plug private futex exec() race
The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer:
exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm;
Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed.
Plug this gap by:
1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release()
2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched.
From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/06/2026
The Linux kernel contains a race condition vulnerability within the private futex implementation during process execution transitions, specifically affecting priority inheritance (pi) futexes. This flaw arises from an insufficient check that verifies whether the memory descriptor associated with a waiter is identical to that of the owner when stored in the futex key and copied into the pi_state structure. While this mechanism generally functions correctly under normal threading conditions, it fails during exec operations due to a critical timing gap where the memory management context is being swapped out but not yet fully released or re-initialized for the new executable image.
During an exec() system call, the kernel undergoes a complex sequence of state changes involving the release of old memory descriptors and the acquisition of new ones. The vulnerability manifests in the interval between the execution of futex_exec_release and the actual assignment of the new mm pointer to the task structure. In this window, the exit_state field is temporarily set to EXITING while robust list cleanup occurs, but before it is reset to OK after the memory descriptor switch. If a waiter attempts to acquire or release a private pi-futex owned by a process undergoing exec() during this specific interval, the kernel may incorrectly determine that the owner's memory context has changed in a way that invalidates the lock ownership, leading to incorrect state transitions and potential data corruption or deadlock scenarios.
The operational impact of this vulnerability includes potential denial of service through deadlocks where threads become permanently blocked waiting for futexes held by processes in mid-execution transition. Additionally, there is a risk of use-after-free conditions if the kernel references memory descriptors that are about to be freed but have not yet been fully dereferenced due to the race condition. This can lead to system instability, crashes, or unpredictable behavior in multi-threaded applications relying on precise synchronization primitives provided by private futexes with priority inheritance enabled.
To mitigate this issue, the kernel developers implemented a fix that modifies how the task's futex exit state is managed during exec operations. The solution involves setting tsk::futex::exit_state to FUTEX_STATE_DEAD within futex_exec_release() immediately after robust list cleanup begins, rather than leaving it in an ambiguous EXITING state. Subsequently, the state is only set back to FUTEX_STATE_OK after the memory descriptor has been successfully switched and stabilized. This ensures that from a futex perspective, any task undergoing exec is treated as dead until its new execution context is fully established, thereby eliminating the window where incorrect mm checks could occur.
This vulnerability aligns with CWE-362, which describes concurrent execution issues resulting in race conditions due to improper synchronization of shared resources. From an ATT&CK perspective, this type of kernel-level race condition can be leveraged for privilege escalation or denial of service attacks against systems relying on complex inter-process communication and synchronization mechanisms. The fix reinforces the integrity of process state management during critical transitions, ensuring that resource ownership checks remain valid even under high-concurrency scenarios involving dynamic executable loading. System administrators should ensure their Linux kernels are updated to versions containing this patch to prevent potential exploitation in environments where private pi-futexes are actively used for performance-critical synchronization tasks.