CVE-2026-80778: Linux Kernel Race Condition Vulnerability

CVE-2026-80778 Overview

CVE-2026-80778 is a Linux kernel vulnerability in the futex priority-inheritance (PI) subsystem. The flaw allows a private futex key to be attached to a PI owner residing in a different memory descriptor (mm). Because private futex keys borrow the waiter's mm without taking an mm_users reference, a concurrent teardown of the waiter's mm can free the futex hash while a foreign PI owner still references it. The result is a use-after-free condition triggered during exit_pi_state_list() cleanup. The upstream fix rejects cross-mm private futex owners inside attach_to_pi_owner().

Critical Impact
A local unprivileged attacker able to coordinate futex operations across processes can trigger a kernel use-after-free, leading to memory corruption, denial of service, or potential local privilege escalation.

Affected Products

Linux kernel (mainline) prior to the commits landing the futex/pi: Reject cross-mm private futex owners fix
Linux kernel stable trees receiving backports referenced by commits 2b92e55, 43b148d, 59b3732, and f7fb3e07
Distributions shipping vulnerable stable kernels until vendor backports are applied

Discovery Timeline

2026-09-04 - CVE-2026-80778 published to NVD
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80778

Vulnerability Analysis

The Linux futex subsystem supports priority-inheritance (PI) futexes to prevent priority inversion between waiters and lock owners. Private futexes are scoped to a single address space, and their keys are derived using the waiter's mm pointer without acquiring an mm_users reference. This is safe only while every consumer of the key lives inside the same mm.

The function attach_to_pi_owner() accepted an owner task from a different address space and copied the waiter's private key into the owner's PI state. When that foreign owner later exited, exit_pi_state_list() used the borrowed key to locate the hash bucket and take a reference on the waiter's private futex hash. If the waiter's mm was concurrently torn down, futex_hash_free() released the hash while the surviving PI owner still held a pointer into it, producing a use-after-free on kernel memory.

Root Cause

The root cause is missing address-space validation in attach_to_pi_owner(). Private futex keys carry an implicit lifetime tied to the waiter's mm, but the PI attach path did not enforce that the prospective owner shared that same mm. This is a lifetime and ownership bug in the futex PI state machine, closely related to a race condition between PI owner exit cleanup and mm teardown.

Attack Vector

Exploitation requires local code execution and the ability to arrange a PI futex whose owner runs in a different address space than the waiter, then race the waiter process teardown against the owner's exit_pi_state_list() path. The vulnerability manifests in kernel memory management structures rather than in userspace, so successful exploitation typically results in kernel memory corruption. See the upstream commits referenced below for the exact code paths involved.

// No verified exploit code is publicly available. The fix in
// attach_to_pi_owner() validates, under the owner's pi_lock and
// after checking owner state, that owner->mm == current->mm for
// PI operations on a private futex key. Mismatched mm values are
// rejected before the private key is copied into the owner's PI state.

Detection Methods for CVE-2026-80778

Indicators of Compromise

Unexpected kernel oops or panic messages referencing exit_pi_state_list, futex_hash_free, or attach_to_pi_owner in dmesg or the systemd journal
KASAN use-after-free reports naming futex hash bucket allocations on kernels built with KASAN enabled
Repeated process crashes correlated with heavy futex PI activity across process boundaries

Detection Strategies

Inventory running kernel versions across Linux fleet and compare against the fixed commits (2b92e55, 43b148d, 59b3732, f7fb3e07) or the vendor-provided patched build numbers
Monitor kernel ring buffer telemetry for futex-related warnings, BUG_ON traces, or KASAN splats
Correlate short-lived processes performing FUTEX_LOCK_PI or FUTEX_TRYLOCK_PI operations with concurrent parent exits

Monitoring Recommendations

Forward /var/log/kern.log, dmesg, and journalctl -k output to a centralized logging platform and alert on futex-related stack traces
Enable audit rules for the futex syscall on high-value hosts to establish a baseline of PI futex activity
Track kernel package versions through configuration management and flag hosts running unpatched stable kernels

How to Mitigate CVE-2026-80778

Immediate Actions Required

Apply vendor-supplied kernel updates that include the futex/pi: Reject cross-mm private futex owners fix as soon as they are available
Prioritize patching multi-tenant Linux hosts, container hosts, and shared build systems where local unprivileged users can execute arbitrary code
Reboot systems after kernel package installation to ensure the fixed kernel is active

Patch Information

The fix is available in the upstream Linux kernel via the following commits: Kernel Git Commit 2b92e55, Kernel Git Commit 43b148d, Kernel Git Commit 59b3732, and Kernel Git Commit f7fb3e07. The patch modifies attach_to_pi_owner() to reject a PI owner whose mm differs from the waiter's mm for private futex keys, performing the check with pi_lock held after validating the owner's futex state.

Workarounds

No supported userspace workaround exists; the vulnerable code path is in the kernel futex implementation
Reduce local attack surface by restricting untrusted local users and enforcing least privilege on shared systems until kernels are patched
On systems that support it, consider seccomp policies that constrain futex syscall usage for untrusted workloads, understanding this may break legitimate applications

bash

# Verify running kernel version and package build after patching
uname -r
# Debian/Ubuntu
apt list --installed 2>/dev/null | grep linux-image
# RHEL/Fedora/CentOS
rpm -qa | grep kernel
# Confirm the host has been rebooted into the patched kernel
uptime