CVE-2026-68170
Received Received - Intake

Use-After-Free in Linux Kernel MPTCP Subflow Close

Publication date: 2026-08-10

Last updated on: 2026-08-10

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix stale skb->sk reference on subflow close The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-10
Last Modified
2026-08-10
Generated
2026-08-10
AI Q&A
2026-08-10
EPSS Evaluated
N/A
NVD
CVE-2026-68170
EUVD
EUVD-2026-55556

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This is a use-after-free vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation. It occurs when a subflow is closed improperly, leaving a stale reference to a socket buffer (skb) in the backlog list. A race condition during cleanup allows a freed socket to be accessed later, causing a use-after-free error in mptcp_backlog_purge().

Detection Guidance

This vulnerability is specific to the Linux kernel's MPTCP (Multipath TCP) implementation and may not have direct network detection commands. It involves a use-after-free issue in the MPTCP backlog handling. Detection typically requires kernel logging or crash analysis. Check kernel logs for warnings like 'inet_sock_destruct' or 'use-after-free' related to MPTCP. Commands like 'dmesg | grep -i mptcp' or 'journalctl -k | grep -i mptcp' may help identify issues.

Impact Analysis

This vulnerability could lead to system crashes, data corruption, or potential privilege escalation if exploited. It affects systems using MPTCP, which is common in modern Linux distributions for improved network performance and reliability.

Mitigation Strategies

Apply the kernel patch that fixes this issue. Update your Linux kernel to a version that includes the fix for CVE-2026-68170. If patching is not immediately possible, consider disabling MPTCP functionality if it is not required, by setting 'net.mptcp.enabled=0' via sysctl or kernel boot parameters.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-68170. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart