CVE-2026-80777
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A timing flaw in the Linux kernel can let programs interfere with each other's memory handling during certain shutdown sequences, risking crashes until the kernel is updated.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Medium
What it actually does
Race condition in private futex pi_state mm validation during exec() allows a window where the waiter's mm check returns incorrect results between robust list cleanup and mm swap, enabling use of a soon-to-be-freed mm_struct.
Why it matters to the business
Kernel instability or potential memory corruption in multi-threaded applications using robust futexes under exec(), increasing crash rates and operational risk in Linux environments until patched.
How an attack unfolds
An attacker triggers a private futex operation on a robust list in one thread while concurrently calling exec() in another; the brief window after exit_state is reset but before mm is updated allows the mm mismatch check to pass incorrectly, leading to pi_state referencing a freed mm.
How to fix it
Update the Linux kernel to a version containing the futex_exec_release state machine changes that set FUTEX_STATE_DEAD before mm swap and FUTEX_STATE_OK only after; rebuild and deploy the fixed kernel across all affected systems.
How to confirm the fix worked
Confirm kernel source contains the FUTEX_STATE_DEAD assignment in futex_exec_release and the post-mm-switch FUTEX_STATE_OK reset; test by exercising robust private futex exec sequences under concurrency and verify no mm mismatch warnings or crashes occur.
Typical attack path
- Create threads sharing a private robust futex
- Initiate exec() in the owner thread to enter the cleanup window
- Perform futex wait or lock operations from the waiter thread during the mm-swap gap
- Trigger use of the stale pi_state after mm is freed
How to detect it
Search kernel logs and crash dumps for futex-related warnings around exec or mm release; examine robust list cleanup paths for unexpected state transitions; no public exploit artifacts known.
What your security team should do
- Prioritize kernel updates on systems running multi-threaded applications with robust futex usage
- Monitor for new stable kernel releases containing this fix and schedule rolling reboots
- Review application usage of private robust lists to reduce exposure until patches are applied
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|