CVE-2026-68170: Linux Kernel Use-After-Free Vulnerability

CVE-2026-68170 Overview

CVE-2026-68170 is a use-after-free vulnerability in the Linux kernel's Multipath TCP (MPTCP) subsystem. The flaw resides in the backlog cleanup logic executed when an MPTCP subflow closes. The cleanup traversal ran without holding mptcp_data_lock(), allowing concurrent softirq receive processing on another CPU to race with the teardown path. A concurrent mptcp_data_ready() call could add a backlog entry referencing the closing subflow socket after the cleanup pass, leaving skb->sk pointing at freed memory. A later call to mptcp_backlog_purge() dereferences the stale pointer, producing a warning in inet_sock_destruct() followed by a use-after-free.

Critical Impact
The race condition results in kernel memory corruption through a use-after-free on freed subflow socket memory, reachable via network traffic on hosts using MPTCP.

Affected Products

Linux kernel (versions prior to the fix commits identified in the stable tree)
Systems with MPTCP enabled in the kernel networking stack
Distributions shipping the vulnerable kernel revisions in the net/mptcp subsystem

Discovery Timeline

2026-08-10 - CVE-2026-68170 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68170

Vulnerability Analysis

The defect lives in the MPTCP subflow close path. The backlog list is populated by mptcp_data_ready() under mptcp_data_lock() during softirq receive processing. However, the cleanup of backlog entries referencing a closing subflow was performed inside mptcp_close_ssk() before __mptcp_close_ssk() acquired the subflow socket (ssk) lock, and without mptcp_data_lock() held. This creates a window where two CPUs manipulate the backlog list concurrently without serialization.

While the cleanup loop iterates the backlog on one CPU, a concurrent softirq path on another CPU can invoke subflow_data_ready() → mptcp_data_ready() → __mptcp_add_backlog(), inserting a new entry that references the same ssk. The cleanup may miss that entry, or the concurrent list mutation may corrupt the traversal. Either outcome leaves skb->sk pointing at the ssk after it is freed. A subsequent mptcp_backlog_purge() dereferences the stale pointer.

Root Cause

The root cause is a locking rule violation: an operation that mutates the backlog list ran without the lock that protects that list. Insufficient serialization between the subflow teardown path and softirq receive processing permits the race.

Attack Vector

Exploitation requires triggering the race between MPTCP subflow closure and concurrent receive processing. Network-borne MPTCP traffic drives mptcp_data_ready() while a peer or local action closes a subflow. Verified code examples for exploitation are not available. See the kernel patch commit and the follow-up commit for the corrective changes.

Detection Methods for CVE-2026-68170

Indicators of Compromise

Kernel warnings from inet_sock_destruct() reporting non-zero sk_rmem_alloc on socket destruction
Kernel oops or panic traces referencing mptcp_backlog_purge in the call stack
Unexpected TCP or MPTCP socket teardown errors logged to dmesg on hosts using multipath TCP

Detection Strategies

Monitor kernel ring buffer output for MPTCP-related warnings, WARN_ON fires, and use-after-free reports from KASAN-enabled builds
Correlate kernel crash telemetry with hosts that have net.mptcp.enabled=1 and active MPTCP connections
Track abnormal socket destruction paths through eBPF probes attached to inet_sock_destruct and mptcp_close_ssk

Monitoring Recommendations

Forward kernel.emerg and kernel.alert syslog facilities to a central log store for pattern matching on MPTCP stack traces
Capture kdump vmcore artifacts on affected hosts to enable post-mortem confirmation of the use-after-free signature
Inventory hosts with MPTCP enabled and prioritize them for kernel version auditing

How to Mitigate CVE-2026-68170

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits 625fc606 and bd7aae44 as soon as vendor builds are available
Identify all Linux hosts with MPTCP enabled and prioritize them for patching, particularly network-facing systems
Where patching is not immediately possible, disable MPTCP via sysctl net.mptcp.enabled=0 to eliminate the vulnerable code path

Patch Information

The fix moves the backlog cleanup into __mptcp_close_ssk(), executed after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The unprotected traversal is removed from mptcp_close_ssk() entirely. Any concurrent mptcp_data_ready() either completes its enqueue before the purge and is caught, or observes closing=1 and bails out. Reference commits: 625fc60608648 and bd7aae448f6ee.

Workarounds

Disable MPTCP system-wide with sysctl -w net.mptcp.enabled=0 and persist the setting in /etc/sysctl.d/
Restrict applications from creating IPPROTO_MPTCP sockets via seccomp or LSM policy where feasible
Segment MPTCP-enabled hosts from untrusted networks until patched kernels are deployed

bash

# Disable MPTCP at runtime and persist across reboots
sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled=0' | sudo tee /etc/sysctl.d/99-disable-mptcp.conf

# Verify the setting
sysctl net.mptcp.enabled