Anthropic, the LLM provider, reported on 27 October a remotely exploitable use-after-free bug in the Linux kernel's multipath TCP (MPTCP) subsystem, affecting systems with MPTCP listeners open. Two days later, the Go security team issued an advisory pointing out that Go programs use multipath TCP by default — a reminder that the affected surface extends well beyond hosts where an operator deliberately enabled the feature.
The race at the heart of the bug
The flaw is a race condition in MPTCP's connection-establishment path. When a retransmitted SYN packet arrives, the kernel generates a response on one thread at nearly the same moment another thread completes the TCP connection. The first thread then accesses the connection's options structure after it has already been freed — a classic use-after-free that, in kernel space, is a viable route to remote code execution.
The structure of MPTCP helps explain why the race surfaces here rather than in plain TCP. Standard connection setup is comparatively linear; MPTCP layers subflow management, path scheduling and additional handshake state on top of it, so connection completion touches more objects across more execution paths — and that added concurrency surface is where the freed object becomes reachable again.
On the fix itself, the described remedy is to only free the structure after an RCU grace period, ensuring the racing thread can no longer reach it once the connection has been torn down.
Why MPTCP draws attention
One reading worth weighing, and it is this publication's analysis rather than disclosure content: MPTCP is a comparatively young subsystem that plausibly draws on a smaller reviewer and fuzzer footprint than core TCP. If that holds, a remotely reachable race in a widely deployed subsystem reads as a reminder that mature, foundational code still harbours this class of bug — and that less-examined corners are where such bugs tend to survive longest.
Downstream exposure is the more concrete story, and here the reporting speaks for itself. The Go security team's 29 October advisory puts Go services in scope by default, which means plenty of deployments run MPTCP listeners without anyone on the operations side having made an explicit choice about them.
What operators should do
- Audit first. Inventory listening sockets for MPTCP capability. MPTCP can be enabled per-socket, and it may not appear in firewall rules or process tables in any obvious way — many operators will not know the subsystem is active on their hosts. Go services are in scope by default under the Go team's advisory. This is the least obvious and most actionable step.
- Patch with priority. Debian users can move now: a note on the LWN thread points to DSA-6568-1, updating the linux package to 6.12.113-1 — worth confirming against the Debian security tracker before deployment. Administrators on other distributions should track vendor advisories and apply backports as they land upstream.
- Mitigate where patching lags. Disable MPTCP socket options on exposed services, or filter inbound SYN traffic to affected listeners as a stopgap.
Perspective
Two points carry forward from this report. First, a subsystem as fundamental as TCP is not exempt from remotely reachable races, and downstream exposure now runs through language runtimes as well as kernels — an advisory that only names the kernel undercounts who is affected. Second, on this publication's analysis, MPTCP's comparatively thin reviewer and fuzzer coverage suggests the bug survived in part because scrutiny there has been thin, independent of who reported it.
The practical relevance for operators is generic but real: any host exposing MPTCP-capable listeners — including edge and network-function deployments where multipath features are attractive — falls within the attack surface until patched. For most readers, the socket audit is tomorrow morning's task.
LLM 供應商 Anthropic 於 10 月 27 日報告 Linux kernel 的 multipath TCP（MPTCP）子系統中存在一個可遠端利用的 use-after-free 漏洞，影響開啟 MPTCP listener 的系統。兩日後，Go security team 發出通告，指出 Go 程式預設使用 multipath TCP——提醒受影響的範圍遠超乎由營運者刻意啟用該功能的主機。
漏洞核心的競態條件
該漏洞是 MPTCP 連接建立路徑中的 race condition。當重傳的 SYN packet 到達時，kernel 會在其中一條 thread 上幾乎與另一條 thread 完成 TCP 連接的同一時刻生成回應。首條 thread 隨後在連接的 options structure 已被釋放後對其進行存取——這是典型的 use-after-free，在 kernel space 中可作為 remote code execution 的可行途徑。
MPTCP 的結構有助解釋為何 race 在此而非普通 TCP 浮現。標準連接建立相對線性；MPTCP 在其之上疊加 subflow 管理、path scheduling 及額外的 handshake 狀態，因此連接完成時會涉及更多物件及更多執行路徑——正是這額外的 concurrency surface，使已釋放的物件得以再次被觸及。
就修正本身而言，所述的補救方法是要在 RCU grace period 之後才釋放該 structure，確保連接被拆除後競態中的 thread 已無法再觸及它。
為何 MPTCP 備受關注
一個值得衡量的解讀——這是本刊的分析，並非披露內容：MPTCP 是一個相對年輕的子系統，其 reviewer 及 fuzzer 覆蓋面很可能較核心 TCP 為小。倘若如此，在一個廣泛部署的子系統中出現可遠端觸及的 race，便提醒我們成熟而基礎的程式碼仍藏有這類 bug——而較少受審視的角落正是此類 bug 最能長期存活之處。
下游的暴露面是較為具體的故事，而這方面報道本身已足以說明問題。Go security team 於 10 月 29 日發出的通告，使 Go 服務預設已在此範圍之內，即表示大量部署正在執行 MPTCP listener，而營運方並無任何人對此作出明確選擇。
營運者應採取的行動
- 先作審計。 盤點 listening socket 是否具備 MPTCP 功能。MPTCP 可按 socket 啟用，而且未必以任何明顯方式出現在 firewall 規則或 process table 中——不少營運者不會知道相關子系統在其主機上處於啟用狀態。根據 Go 團隊的通告，Go 服務預設已在此範圍之內。此為最不明顯但最具可操作性的一步。
- 優先修補。 Debian 用戶現已可以行動：LWN 討論串中有留言指向 DSA-6568-1，將 linux 套件更新至 6.12.113-1——部署前值得對照 Debian security tracker 核實。其他發行版的管理員應追蹤供應商通告，並在修正進入 upstream 後即時套用 backport。
- 修補滯後時先行緩解。 在對外服務上停用 MPTCP socket option，或在過渡期間過濾流向受影響 listener 的 inbound SYN 流量。
觀點
此報告有兩點值得延續思考。其一，TCP 這樣基本的子系統並不能免疫於可遠端觸及的 race，而下游的暴露面如今除 kernel 外亦延伸至語言 runtime——只點名 kernel 的通告會低估受影響者的範圍。其二，就本刊的分析而言，MPTCP 相對薄弱的 reviewer 及 fuzzer 覆蓋面表示，該 bug 部分因該處審視力量薄弱而得以存活，與由誰報告無關。
對營運者的實際意義雖屬一般但確實存在：任何暴露具 MPTCP 功能的 listener 的主機——包括 multipath 功能具吸引力的 edge 及 network function 部署——在修補前均處於 attack surface 之內。對大多數讀者而言，socket 審計就是明早的任務。