CVE-2026-68170: mptcp: fix stale skb->sk reference on subflow close
- Is it exploited?
Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of . If CISA adds it, this page shows it as known exploited.
- How likely is exploitation in the next 30 days?
- 0.5%
EPSS score, percentile 43.9 of all scored records. A probability estimated by FIRST, not a report of exploitation.
- How severe?
- 9.8 Critical
CVSS v3.1 base score, given by the CNA
- What should I do?
CISA has set no required action, because the vulnerability is not in KEV.
The CVE record links no vendor advisory, patch or mitigation.
- Which versions are affected?
Affected
- 6.19
Unaffected before 6.19; 7.1.6; 7.2
Source: CISA KEV 2026.10.29, as of ; FIRST EPSS, as of ; CVE List, as of . About the data.
What to do
Advisories and patches
The CVE record links no vendor advisory, patch or mitigation.
This summary is based on the CVE record as of . Check the vendor's advisory before you act: affected versions and fixes can change.
Affected products and versions
As listed in the CVE record.
| Status | Versions |
|---|---|
| Affected | from ee458a3f314e to before 625fc6060864 |
| Affected | from ee458a3f314e to before bd7aae448f6e |
Versions not listed are: unaffected.
| Status | Versions |
|---|---|
| Affected | 6.19 |
| Unaffected | before 6.19 |
| Unaffected | 7.1.6 |
| Unaffected | 7.2 |
Versions not listed are: affected.
Versions the record lists as unaffected: 7.1.6, 7.2.
Source: CVE List, as of . About the data.
About this vulnerability
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_da…
Summary: CVE record, as of .
- CISA has not added CVE-2026-68170 to its Known Exploited Vulnerabilities (KEV) catalog, as of 29 Oct 2026.
- The CVE record was published on 10 Aug 2026.
- The CVE record carries a CVSS v3.1 base score of 9.8 (Critical), given by its CNA.
- FIRST's EPSS model puts the probability of exploitation in the next 30 days at 0.5% (percentile 43.9), as of 29 Oct 2026. EPSS is a statistical estimate, not a report of exploitation.
Source: CISA KEV 2026.10.29, as of ; CVE List, as of ; FIRST EPSS, as of . About the data.
Description
mptcp: fix stale skb->sk reference on subflow close
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.
Source: CVE List, as of . About the data.
Timeline
| Date | Event |
|---|---|
| CVE record published | |
| CVE record last updated |
References
2
Known exploited Linux vulnerabilities
- CVE-2026-46300: Linux Kernel Missing Initialization of a Variable Vulnerability
- CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability
- CVE-2025-39964: Linux Kernel Race Condition Vulnerability
- CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability
- CVE-2026-53362: Linux Kernel Unspecified Vulnerability