Linux Kernel up to 7.1.5/7.2-rc4 mptcp mptcp_backlog_purge use after free

Summaryinfo

A vulnerability was found in Linux Kernel up to 7.1.5/7.2-rc4 and classified as very critical. Impacted is the function mptcp_backlog_purge of the component mptcp. Such manipulation leads to use after free. This vulnerability is traded as CVE-2026-68170. The attack may be launched remotely. There is no exploit available.

Detailsinfo

A vulnerability, which was classified as very critical, has been found in Linux Kernel up to 7.1.5/7.2-rc4. Affected by this issue is the function mptcp_backlog_purge of the component mptcp. The manipulation with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2026-68170 since 07/30/2026. The exploitation is known to be easy. The attack may be launched remotely. No form of authentication is required for exploitation. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $5k-$25k (estimation calculated on 08/10/2026).

Upgrading to version 7.1.6 or 7.2-rc5 eliminates this vulnerability. Applying the patch 625fc6060864889fe3d370cdeffbbab762af3cb4/bd7aae448f6ee9d82599a4474664de1e6e91a535 is able to eliminate this problem.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4
• 7.1.5
• 7.2-rc1
• 7.2-rc2
• 7.2-rc3
• 7.2-rc4

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion