Cloudanix VulnDB

CVE-2026-80777

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Create threads sharing a private robust futex
  2. Initiate exec() in the owner thread to enter the cleanup window
  3. Perform futex wait or lock operations from the waiter thread during the mm-swap gap
  4. 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