CVE-2026-80778

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of certain synchronization objects can let one program accidentally use memory that another program has already freed, which may crash the system or allow an attacker to gain more control.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: High
Impact: Privilege Gain
Component: OS kernel
Class: Use After Free
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Use-after-free in attach_to_pi_owner() and exit_pi_state_list() for private futexes: a waiter mm is borrowed without reference and the private key is copied to an owner in a different address space; on owner exit the saved key references a hash bucket that may be freed by concurrent waiter-mm exit.

Why it matters to the business

Kernel memory corruption or crash on systems running affected Linux kernels; successful exploitation can lead to denial of service or local privilege escalation, affecting any workload that uses robust private futexes.

How an attack unfolds

An attacker creates private futexes in two separate processes, arranges for one to wait on a PI futex owned by the other, then triggers concurrent exit of both address spaces so that exit_pi_state_list() dereferences a freed futex hash bucket.

How to fix it

Apply the upstream fix that adds an mm equality check inside attach_to_pi_owner() under pi_lock after validating owner state; rebuild and deploy updated Linux kernels containing the patch to all affected systems.

How to confirm the fix worked

Confirm the source contains the mm comparison in attach_to_pi_owner() performed with pi_lock held; verify running kernels are built from trees that include the referenced commit or later.

Typical attack path

Create two processes with distinct mm_structs
Establish a private PI futex wait relationship between them
Trigger simultaneous exit of owner and waiter processes
Race exit_pi_state_list() against futex_hash_free() to obtain UAF on the hash bucket

How to detect it

Inspect kernel crash logs and core dumps for futex-related oops or warnings referencing exit_pi_state_list or futex_hash_free; correlate with process exit events involving robust private futexes.

What your security team should do

Prioritize kernel updates on all Linux hosts within the next maintenance window
Monitor vendor advisories for backported fixes in distribution kernels
Restrict untrusted code execution on systems until patches are applied

The record

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 ]

Affected packages

Ecosystem	Package	Introduced	Fixed