CVE-2026-80784: Linux Kernel MPTCP Race Condition Vulnerability

CVE-2026-80784 Overview

CVE-2026-80784 is a race condition in the Linux kernel's Multipath TCP (MPTCP) path manager (PM) subsystem. The flaw allows a memory leak when a userspace PM ANNOUNCE genl operation runs concurrently with socket teardown on the same msk (MPTCP socket). Under sustained concurrent load, mptcp_pm_add_addr and mptcp_pm_addr_entry objects leak because entries are appended to list heads that no code path later iterates for the destroyed socket. The issue was discovered using an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).

Critical Impact
Repeated triggering of the race leads to sustained kernel memory exhaustion, degrading availability of systems that expose the MPTCP userspace path manager.

Affected Products

Linux kernel with MPTCP userspace path manager enabled
Kernel versions prior to the fixes referenced in the stable tree commits
Distributions shipping affected upstream MPTCP code

Discovery Timeline

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

Technical Details for CVE-2026-80784

Vulnerability Analysis

The defect is a race between mptcp_pm_destroy() and userspace PM ANNOUNCE handlers operating on the same msk. mptcp_pm_destroy() empties msk->pm.anno_list and msk->pm.userspace_pm_local_addr_list under msk->pm.lock, releasing the lock between the two list operations. A concurrent mptcp_pm_nl_announce_doit() handler holds a socket reference through mptcp_token_get_sock() and invokes mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(), each of which briefly acquires msk->pm.lock to append entries.

Because the genl handler holds a socket reference, mptcp_pm_destroy() can run on the same msk through mptcp_disconnect() and mptcp_destroy_common() before the handler completes. When lock acquisitions interleave adversely, the destroy path empties a list first, then the allocation path appends to a list head that no code later iterates. The freshly added entry becomes unreachable, and kmemleak reports both mptcp_pm_add_addr and mptcp_pm_addr_entry objects leaking under sustained ANNOUNCE plus close load.

Root Cause

The root cause is a missing synchronization signal between the teardown path and concurrent allocators sharing msk->pm.lock. The lock alone does not encode socket lifecycle state, so allocators cannot distinguish a live path manager from one already in teardown. This is a classic [CWE-362] race condition combined with a [CWE-401] missing release of memory after effective lifetime.

Attack Vector

A local process with permission to issue MPTCP generic netlink operations can repeatedly issue ANNOUNCE calls against sockets that are being closed. Sustained interleaving forces the race window open, causing incremental kernel memory leaks. The upstream fix introduces an MPTCP_PM_DESTROYING bit in msk->pm.status, set by mptcp_pm_destroy() under pm.lock before lists are emptied and checked by allocators under the same lock. Either the allocator wins the lock and its entry is freed by the destroy path, or the destroy path wins and the allocator observes the bit and refuses to append.

No public proof-of-concept exploit code has been published. See the Linux Kernel Commit b2a0b55 and related stable tree commits for the exact fix.

Detection Methods for CVE-2026-80784

Indicators of Compromise

kmemleak reports referencing mptcp_pm_add_addr or mptcp_pm_addr_entry allocations that are never freed.
Steady growth of kernel slab consumption on hosts running MPTCP with the userspace path manager enabled.
Repeated MPTCP ANNOUNCE generic netlink operations correlated with socket close activity on the same tokens.

Detection Strategies

Enable CONFIG_DEBUG_KMEMLEAK on test kernels and review /sys/kernel/debug/kmemleak for MPTCP PM allocations.
Track slab usage over time with slabtop and per-cache counters in /proc/slabinfo for MPTCP-related caches.
Audit generic netlink activity to the MPTCP PM family to identify processes issuing high-frequency ANNOUNCE requests.

Monitoring Recommendations

Collect kernel memory metrics (MemAvailable, Slab, SReclaimable, SUnreclaim) and alert on sustained growth without matching workload increase.
Log MPTCP netlink command counts per process using auditd or eBPF probes on genl_rcv_msg.
Correlate host memory pressure events with MPTCP subflow churn on multipath-enabled workloads.

How to Mitigate CVE-2026-80784

Immediate Actions Required

Inventory Linux hosts that build with CONFIG_MPTCP=y and expose the userspace path manager to unprivileged or containerized workloads.
Apply the stable kernel updates that include the MPTCP_PM_DESTROYING status bit fix, then reboot affected systems.
Restrict access to the MPTCP generic netlink family to trusted administrative processes until patches are deployed.

Patch Information

The upstream fix adds an MPTCP_PM_DESTROYING bit in msk->pm.status, set under pm.lock before list teardown and checked under pm.lock by both mptcp_userspace_pm_append_new_local_addr() and mptcp_pm_announced_alloc(). Backports are available across stable branches. Refer to the fixes in Linux Kernel Commit 6c29091, Linux Kernel Commit 9fe5eeb, Linux Kernel Commit b2a0b55, Linux Kernel Commit bb32e9a, Linux Kernel Commit efc33b5, and Linux Kernel Commit f483418.

Workarounds

Disable MPTCP where it is not required by setting net.mptcp.enabled=0 through sysctl.
Prefer the in-kernel path manager over the userspace path manager where feasible to avoid the affected code paths.
Constrain generic netlink access to the MPTCP PM family using capability restrictions and container seccomp profiles.

bash

# Configuration example
sysctl -w net.mptcp.enabled=0
sysctl -w net.mptcp.pm_type=0