2026 年 10 月，一批英文報導把 CVE-2026-98432 寫成「MPTCP 漏洞」，標題再加一句「Linux 伺服器可被 remote root」。兩句都不準確。CVE 記錄與上游修補指向 net/ipv4 的一般 IPv4 TCP 交握路徑，MPTCP 只在 Anthropic 實驗室的 exploit 設定中出現；已演示的 remote root 是未公開的單一設定，不是這個漏洞的通例。
先修正前提：這不是 MPTCP 漏洞
CVE 正式標題為「ipv4: free inet_opt and ireq_opt after an RCU grace period」，受影響檔案是 net/ipv4/af_inet.c 與 tcp_ipv4.c，即所有 IPv4 TCP 共用的收連線路徑。觸發不需 CONFIG_MPTCP，不需 netfilter，也不需特殊 kconfig。IPv6 主問題不受影響，因為 tcp_v6_syn_recv_sock() 會複製選項。
缺陷位置：指針交給 child socket，卻沒有複製
交握完成時，tcp_v4_syn_recv_sock() 把請求 socket 的 ireq->ireq_opt 直接交給 child socket，成為 newinet->inet_opt，沒有先複製，同一個 ip_options_rcu 物件於是被兩處引用。
釋放方式才是問題。inet_sock_destruct() 與 tcp_v4_reqsk_destructor() 都以普通 kfree() 釋放它；只要另一個 CPU 仍在 ip_build_and_send_pkt() 內、經 ip_options_build() 讀取 opt->optlen 並把 opt->__data 複製進 SYN-ACK，物件就可能已被釋放。
後果是讀到過期長度而把堆積記憶體回傳對端、寫入已釋放物件造成破壞，或核心 panic 形成遠端阻斷服務。CNA 給 C:H 的理由，正是這個按過期長度複製進 SYN-ACK 的動作。
觸發條件：listening IPv4 TCP 加一個帶選項的 SYN
三項條件同時成立：有監聽中的 IPv4 TCP socket；SYN 帶 Record Route 或 Timestamp 選項；同一 SYN 被重送，令交握完成或拆除與選項讀取撞在同一時間窗。全程在應用層認證之前，不需憑證與互動，故 remote、pre-auth 在核心層面準確。
缺陷由 commit 079096f103faca2dd87342cca6f23d4b34da8871 引入，首個受影響版本為 4.4。另有需 tcp_migrate_req=1（預設關）或 BPF 程式的遷移變體。防火牆若丟棄帶 IP option 的 SYN，或主機沒有對外開放 IPv4 TCP，攻擊面就不存在。
修復：兩處 kfree() 改為 kfree_rcu()
補丁由 Eric Dumazet 撰寫、Anthropic 的 Xinyang Ge 回報，Kuniyuki Iwashima 審閱，Jakub Kiciński 提交。兩個檔案各一行新增、一行刪除，就是把上述 destructor 的 kfree() 換成 kfree_rcu()：物件要等一個 RCU grace period 後才歸還，仍在讀取的 CPU 受保護，race 窗口關閉。核心 CVE 團隊不建議單獨 cherry-pick，應升級到所屬分支的修復版本。
CVE 時序與 9.8 分：CNA 給分，NVD 未評
CVE 於 9 月 25 日 10:25:14Z 預留，CNA 於 10 月 15 日 12:08:22Z 公開，NVD 同日 13:17:13Z 建立記錄；截至 11 月 1 日 NVD 狀態仍是「Received」，最後修改 10 月 31 日 21:16:53Z，即已收錄但未完成自身分析。
9.8 分是 kernel.org CNA 的 CVSS v3.1 評分，向量 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，在 NVD 以 Secondary metric 呈現，NVD 欄位寫着「Base Score N/A — NVD assessment not yet provided」。說「NVD 評 9.8」是錯的。Ubuntu 優先級列 High 卻同時印出 9.8，Red Hat 為 Critical 9.8；第三方稱 Red Hat 評 8.1 屬過時報導。
修復版本清單
| 分支 | 修復版本 | 日期 |
|---|---|---|
| 7.2 | 7.2.10 | 2026-10-11 |
| 6.18 | 6.18.56 | 2026-10-11 |
| 6.12 | 6.12.113 | 2026-10-15 |
| 6.6 | 6.6.159 | 2026-10-15 |
| 6.1 | 6.1.190 | 2026-10-15 |
| 5.15 | 5.15.223 | 2026-10-15 |
| 5.10 | 5.10.272 | 2026-10-15 |
| mainline | 7.3（7.3-rc7 合入） | 2026-10-18 |
4.4 至 5.4 的停止維護分支沒有上游修復，只能靠發行版回補。判斷是否已修，看版本號是否達到上表數字，而非「已是最新」的提示。
發行版現況：Ubuntu 與 RHEL 未修，Debian 與 Fedora 已修
截至 11 月 1 日情況分歧。Ubuntu 追蹤頁（10 月 30 日更新）把 linux 在多個版本標為「Vulnerable — work in progress」：26.10 為 7.3.0-10.10、26.04 為 7.0.0-43.43、24.04 為 6.8.0-149.149、22.04 為 5.15.0-203.213；20.04、18.04、16.04 直接列 Vulnerable，期內未發 USN。
Red Hat 公告 RHSB-2026-016 於 10 月 15 日公開、10 月 30 日更新，狀態「Ongoing」、Critical，RHEL 8、9、10 與 OpenShift 均在名單；其 nftables 緩解規則丟棄 IP 標頭長度大於 5 的入站 TCP，但明言不能取代修補。
Debian 已修：bookworm 6.1.190-1（DLA-4841-1）、linux-6.12 6.12.113-1~deb12u1（DLA-4850-1）、trixie 6.12.113-1（DSA-6568-1）、forky 7.2.12-1、sid 7.2.14-1。Fedora 的 F43、F44 為 7.2.13（10 月 28 日），F45 為 7.2.13（10 月 31 日），均高於 7.2.10。AlmaLinux 修補核心 10 月 30 日入測試庫；SUSE 據報導部分已修，本次未覆核。
Anthropic 稱 Claude 寫出 exploit：只針對 MPTCP listener，未公開、未重現
10 月 27 日，Anthropic 前沿紅隊發表「Discovering vulnerabilities with Claude」，稱在初步提示後，未公開的內部研究模型 Claude 寫出可用 exploit：遠端向設有多重路徑 TCP listener 的 Linux 伺服器送封包，無需憑證即可取得 root。鏈條兩段：先以 race 令核心讀取攻擊者控制的長度並回傳超額位元組，洩漏核心指標；再以緩衝區溢出覆寫回呼函式指標。洩漏約 48 分鐘，再約 5 分鐘取得 shell。
限制必須一起讀：來源只有 Anthropic 一方，無獨立重現，程式碼未公開，公開 PoC 不存在，亦不在 CISA KEV。MPTCP listener 是 exploit 前提，不是漏洞前提：CVE 記錄與修補沒提及 MPTCP，Anthropic 也沒解釋。可確定的是「該實驗室設定下可 remote root」，不能推廣成「所有 Linux 伺服器可被 remote root」；一般主機的可證後果仍是記憶體洩漏、破壞與遠端阻斷服務。
家用實務建議：先問這台機有沒有對外開 IPv4 TCP
對家庭用戶，問題不是核心有沒有這個 bug，而是哪一台機的 IPv4 TCP 端口真的暴露在公網：
- 路由器：多數跑廠商核心（4.4、5.4、5.10 系），暴露面是 WAN 管理介面、VPN 與端口轉發。關掉 WAN 側管理與 UPnP，等廠商固件；不要裝 mainline 核心。
- NAS：家用最現實的暴露點，同時開 SMB、網頁介面、同步與 SSH。裝廠商固件並重啟，未修前不要放上公網。
- Linux 桌面與伺服器：以
uname -r對照上表或發行版追蹤頁，安裝後必須重啟；Ubuntu 用戶 11 月 1 日仍未有修復。 - 容器與 Kubernetes 節點：共用宿主核心，換映像無用，要升級節點。
若必須對外開放又暫無法修補，可用上述 nftables 規則；它可能影響特殊流量，且只收窄攻擊面。
常見問題
家用路由器需要立即處理嗎？
先確認有否把 IPv4 TCP 端口開在 WAN 側。只作 NAT 與區網閘道、遠端管理與 UPnP 已關，可達性很低；有端口轉發或對外 VPN 就先關閉。
9.8 分等於所有伺服器可被 remote root 嗎？
不是。那是 CNA 按最壞情況給的向量分數；已演示的 remote root 只在 Anthropic 未公開的實驗室 PoC，且限定 MPTCP listener。
更新後需要重啟嗎？
需要。核心只在下一次開機載入，「已安裝」不代表運行中的核心已修，重啟後以 uname -r 核對。
關閉 MPTCP 是否就安全？
沒有幫助，CONFIG_MPTCP 本就不是觸發條件；IPv6 主問題不受影響，但同時提供 IPv4 服務仍會暴露。
把標題與機制分開之後，這宗 CVE 的形狀很清楚：一個沒有複製的指針、兩處用錯的釋放函式，換來一個在交握階段可達的 use-after-free。真正要判斷的，是你手上哪一台機器的 IPv4 TCP 端口真的向公網開放——你查過自家的端口轉發清單了嗎？
分類：Technology
標籤：Linux 核心 · CVE-2026-98432 · 資訊安全 · use-after-free · IPv4 · 修補更新
