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.
Published: 2026-08-10
Score: 9.8 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw is in the Multi‑Protocol Transport Control Protocol (MPTCP) path of the Linux kernel. During subflow teardown, the backlog cleanup of socket buffers was performed without holding the required data lock, causing a race condition. This race can leave a socket buffer pointing at a socket that has already been freed, leading to a use‑after‑free when the backlog is eventually purged. The weakness is an instance of improper synchronization (CWE‑825).

Affected Systems

Any Linux system that runs a kernel containing the vulnerable MPTCP implementation and has MPTCP enabled is potentially affected. The patch belongs to commit 625fc6060864889fe3d370cdeffbbab762af3cb4; systems whose kernel version predates this commit or does not include that change may be vulnerable. No specific version numbers are listed, so a full inventory check against the commit or kernel sources is recommended.

Risk and Exploitability

The CVSS score of 9.8 indicates high severity, and the EPSS score of < 1% suggests a low likelihood of exploitation at present. The flaw can lead to a kernel crash due to a use‑after‑free during backlog purge. Based on the description, it is inferred that an attacker who can inject MPTCP packets toward the target may trigger the race condition, but there is no confirmed indication that this vulnerability can be leveraged for privilege escalation. The vulnerability requires network traffic to the vulnerable kernel and a period during which a subflow is closing.

Generated by OpenCVE AI on August 13, 2026 at 23:46 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel release that includes commit 625fc6060864889fe3d370cdeffbbab762af3cb4, which fixes the stale reference and adds proper synchronization.
  • Restart the system after installing the new kernel so the updated MPTCP code is active.
  • If a kernel update cannot be performed immediately, disable MPTCP for all interfaces by setting sysctl net.mptcp.mptcp_enabled=0 to eliminate the race condition source.

Generated by OpenCVE AI on August 13, 2026 at 23:46 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 13 Aug 2026 22:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H'}

cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}


Thu, 13 Aug 2026 08:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 12 Aug 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-825
References
Metrics threat_severity

None

cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H'}

threat_severity

Moderate


Mon, 10 Aug 2026 19:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
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.
Title mptcp: fix stale skb->sk reference on subflow close
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-17T05:00:11.808Z

Reserved: 2026-07-30T09:28:09.372Z

Link: CVE-2026-68170

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-10T13:20:03.637

Modified: 2026-08-17T05:18:17.593

Link: CVE-2026-68170

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-10T11:59:39Z

Links: CVE-2026-68170 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-14T00:00:04Z

Weaknesses
  • CWE-825

    Expired Pointer Dereference