{"id":"CVE-2026-68170","state":"PUBLISHED","title":"mptcp: fix stale skb->sk reference on subflow close","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix stale skb->sk reference on subflow close\n\nThe backlog list is updated by mptcp_data_ready() under\nmptcp_data_lock(). The cleanup of backlog references to a closing\nsubflow, however, was performed in mptcp_close_ssk(), before\n__mptcp_close_ssk() acquires the ssk lock, and while holding neither\nthe ssk lock nor mptcp_data_lock().\n\nBecause that traversal ran without mptcp_data_lock(), concurrent softirq\nRX processing on another CPU (subflow_data_ready() -> mptcp_data_ready()\n-> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog\nentry referencing the ssk while the cleanup loop was in progress. Such\nan entry could be missed by the cleanup, or the concurrent list update\ncould corrupt the traversal, leaving skb->sk pointing at the ssk after\nit is freed.\n\nA later mptcp_backlog_purge() then dereferences the stale pointer,\ntriggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0)\nfollowed by a use-after-free in mptcp_backlog_purge().\n\nFix this by moving the backlog cleanup into __mptcp_close_ssk(), after\nsubflow->closing is set to 1 and while the ssk lock is still held,\nserialized under mptcp_data_lock(). The cleanup runs only on the push\npath (MPTCP_CF_PUSH), where backlog references accumulate; on other\nteardown paths the caller already handles cleanup.\n\nWith subflow->closing set and mptcp_data_lock() held across the purge,\nany concurrent mptcp_data_ready() either completes its enqueue before\nthe purge runs and is caught, or observes closing=1 and bails out. Once\nmptcp_data_unlock() is reached, no new skb referencing the ssk can be\nenqueued, so the cleanup is exhaustive.\n\nRemove the unprotected traversal from mptcp_close_ssk() entirely.","publishedAt":"2026-08-10T11:59:39.174Z","updatedAt":"2026-08-17T05:00:11.808Z","severity":{"score":9.8,"label":"Critical","version":"3.1","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"ee458a3f314e9c669ddd227bf5ab08354d9e75cc","status":"affected","lessThan":"625fc6060864889fe3d370cdeffbbab762af3cb4","versionType":"git"},{"version":"ee458a3f314e9c669ddd227bf5ab08354d9e75cc","status":"affected","lessThan":"bd7aae448f6ee9d82599a4474664de1e6e91a535","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/mptcp/protocol.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.19","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.19","versionType":"semver"},{"version":"7.1.6","status":"unaffected","lessThanOrEqual":"7.1.*","versionType":"semver"},{"version":"7.2","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/mptcp/protocol.c"]}],"references":["https://git.kernel.org/stable/c/625fc6060864889fe3d370cdeffbbab762af3cb4","https://git.kernel.org/stable/c/bd7aae448f6ee9d82599a4474664de1e6e91a535"],"weaknesses":[],"ingestedAt":"2026-10-29T20:12:49.727Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2026/68xxx/CVE-2026-68170.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-68170","state":"PUBLISHED","datePublished":"2026-08-10T11:59:39.174Z","dateUpdated":"2026-08-17T05:00:11.808Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2026-07-30T09:28:09.372Z"},"containers":{"cna":{"title":"mptcp: fix stale skb->sk reference on subflow close","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix stale skb->sk reference on subflow close\n\nThe backlog list is updated by mptcp_data_ready() under\nmptcp_data_lock(). The cleanup of backlog references to a closing\nsubflow, however, was performed in mptcp_close_ssk(), before\n__mptcp_close_ssk() acquires the ssk lock, and while holding neither\nthe ssk lock nor mptcp_data_lock().\n\nBecause that traversal ran without mptcp_data_lock(), concurrent softirq\nRX processing on another CPU (subflow_data_ready() -> mptcp_data_ready()\n-> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog\nentry referencing the ssk while the cleanup loop was in progress. Such\nan entry could be missed by the cleanup, or the concurrent list update\ncould corrupt the traversal, leaving skb->sk pointing at the ssk after\nit is freed.\n\nA later mptcp_backlog_purge() then dereferences the stale pointer,\ntriggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0)\nfollowed by a use-after-free in mptcp_backlog_purge().\n\nFix this by moving the backlog cleanup into __mptcp_close_ssk(), after\nsubflow->closing is set to 1 and while the ssk lock is still held,\nserialized under mptcp_data_lock(). The cleanup runs only on the push\npath (MPTCP_CF_PUSH), where backlog references accumulate; on other\nteardown paths the caller already handles cleanup.\n\nWith subflow->closing set and mptcp_data_lock() held across the purge,\nany concurrent mptcp_data_ready() either completes its enqueue before\nthe purge runs and is caught, or observes closing=1 and bails out. Once\nmptcp_data_unlock() is reached, no new skb referencing the ssk can be\nenqueued, so the cleanup is exhaustive.\n\nRemove the unprotected traversal from mptcp_close_ssk() entirely."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"ee458a3f314e9c669ddd227bf5ab08354d9e75cc","status":"affected","lessThan":"625fc6060864889fe3d370cdeffbbab762af3cb4","versionType":"git"},{"version":"ee458a3f314e9c669ddd227bf5ab08354d9e75cc","status":"affected","lessThan":"bd7aae448f6ee9d82599a4474664de1e6e91a535","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/mptcp/protocol.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"6.19","status":"affected"},{"version":"0","status":"unaffected","lessThan":"6.19","versionType":"semver"},{"version":"7.1.6","status":"unaffected","lessThanOrEqual":"7.1.*","versionType":"semver"},{"version":"7.2","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/mptcp/protocol.c"]}],"references":[{"url":"https://git.kernel.org/stable/c/625fc6060864889fe3d370cdeffbbab762af3cb4"},{"url":"https://git.kernel.org/stable/c/bd7aae448f6ee9d82599a4474664de1e6e91a535"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":9.8,"baseSeverity":"CRITICAL"},"scenarios":[{"lang":"en","value":"AV:N - 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.\nAC:L - 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.\nPR:N - 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.\nUI:N - 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.\nS:U - 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.\nC:H - 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.\nI:H - 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.\nA:H - 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."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-08-17T05:00:11.808Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.1.6"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.2"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}}}}}