Look up another CVE · open CVE-2026-68170 in the interactive tracker
CVE-2026-68170
mptcp: fix stale skb->sk reference on subflow close
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem net/mptcp. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-68170 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/mptcp/protocol.c
- What this is
- NETWORKING [MPTCP]MAINTAINERS section matched on net/mptcp/ · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_MPTCP /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_MPTCP
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.52%, higher than 42.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- net/mptcp
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.19 | 7.1.6 | 625fc6060864 |
| 6.19 | 7.2 | bd7aae448f6e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The bug is in MPTCP receive/teardown on the TCP/IP stack; remote peers drive subflow_data_ready() RX softirq processing and can concurrently trigger subflow close via FIN/RST or data floods during mptcp_close_ssk(), reaching the race without local access.
- AC:LAttack complexity, low
- The attacker controls both sides of the race by timing inbound packets against subflow teardown on an MPTCP connection they own; syzkaller reliably reproduced the UAF, and no uncontrollable memory layout or rare victim state is required beyond an active MPTCP session.
- PR:NPrivileges required, none
- Exploitation needs only the ability to be an MPTCP/TCP peer on the network after handshake; no local account, CAP_NET_ADMIN, or application credentials on the victim are required to send data and close subflows remotely.
- UI:NUser interaction, none
- No victim user interaction is required beyond the system normally accepting or maintaining MPTCP connections; the attacker can trigger the race entirely through automated network traffic and connection management.
- S:UScope, unchanged
- The vulnerability corrupts kernel heap memory within the network stack security boundary on the affected host; it does not by itself cross VM, hypervisor, or IOMMU isolation boundaries.
- C:HConfidentiality impact, high
- A missed backlog cleanup leaves skb->sk pointing at a freed subflow socket; later mptcp_backlog_purge() dereferences it in mptcp_borrow_fwdmem(), producing a slab use-after-free on struct sock that can disclose kernel memory.
- I:HIntegrity impact, high
- The UAF performs atomic_sub() writes to sk_rmem_alloc on a freed TCP socket object, corrupting attacker-influenced heap memory and providing a standard path to further arbitrary kernel write or control-flow hijack.
- A:HAvailability impact, high
- Confirmed KASAN slab-use-after-free during mptcp_backlog_purge() causes inet_sock_destruct() warnings and kernel instability during socket teardown; UAF in softirq/close paths can panic or repeatedly crash the host.