十月就有修補，Ubuntu 與 RHEL 仍在等

這篇照時間順序走一遍 CVE-2026-98432：修補怎麼出來、各家發行版什麼時候跟上、嚴重度為什麼被往上調、現在手上能做什麼。資料主要來自 Atlas 的整理頁（10 月 31 日傍晚更新）和 gslin 11 月 1 日的中文文章，再對照 Go Security Team、Red Hat、CloudLinux 與 Anthropic 自己的頁面。只有廠商一方說過的話，文中會寫成「按 Anthropic 的說法」，不當成已驗證的事實；本文也不寫任何利用步驟。

修補先到：10 月 1 日到 18 日

按 Atlas 整理的時間線，10 月 1 日 Eric Dumazet 貼出修補，信裡把報告者記在 Anthropic 的 Xinyang Ge 名下；fix commit 的紀錄是 Dumazet 修、Kuniyuki Iwashima 審。10 月 5 日修補併進核心的 networking tree。這兩步都發生在任何穩定版之前，對使用者真正有意義的日期是後面幾個。

10 月 11 日，7.2.10 與 6.18.56 帶著修補出貨，7.3-rc7 同一晚跟上。10 月 15 日輪到五條較老的長期分支：6.12.113、6.6.159、6.1.190、5.15.223、5.10.272，CVE 記錄也在同一天發布。10 月 18 日 7.3 正式釋出，修補已經在裡面。把這串日期排在一起，上游的節奏很乾淨：從貼出修補到 7.3 釋出，十七天。

還有一個間隔值得單獨記下：10 月 1 日貼出修補，CVE 記錄到 10 月 15 日才發布，中間隔了十四天（算術，非來源說法）。也就是說，五條長期分支出貨的同一天，這個漏洞才有了公開編號。這十四天裡有沒有人從修補內容讀出問題，來源沒有說，我不猜；能確定的只有順序：修補在先，編號在後。合理的推測是，只靠 CVE 清單來觸發更新的流程，會比上游修補晚兩週才看到這個漏洞；盯著穩定版變更紀錄的團隊則不受這個延遲影響。

受影響範圍從哪裡算起？Atlas 的寫法是「Any Linux kernel from 4.4 on that lacks the fix」，也就是 4.4 以後所有沒有這個修補的核心。麻煩在 4.4 到 5.4 這幾條分支：上游已經終止維護，Atlas 的版本表在那一列只寫「distro fixes only」，沒有上游版號可以升。還在跑這些分支的機器，只能等發行版自己 backport。

IPv6 的說法有一個小細節。Atlas 寫「IPv6 connections aren't affected by the main issue」，而它引用的 commit 措辭是「IPv6 is not affected by the first issue」。字面上，「first issue」暗示不只一個問題；合理的推測是 IPv6 路徑另有待處理的部分，但我讀到的來源沒有給細節，這裡不往下猜。

如果你手上有 uname -r 的輸出，下面這個小工具把它對照到上游的修補版號。它只回答「這條上游分支修了沒有」，不回答「你的發行版核心修了沒有」。Debian bookworm 的 6.1.190-1 剛好和上游同號，但經過 backport 的發行版核心版號未必對得上，這是我的提醒，不是來源的說法。

輸入核心版號，對照上游分支的修補版號 · 9 條分支

核心版號（uname -r 的前段，例如 6.1.185）

6.1.185 低於 6.1.190。上游 6.1 分支的修補在 6.1.190（10 月 15 日出貨）。若這是發行版核心，以廠商 advisory 為準。

7.2 → 7.2.10 · 6.18 → 6.18.56 · 6.12 → 6.12.113 · 6.6 → 6.6.159 · 6.1 → 6.1.190 · 5.15 → 5.15.223 · 5.10 → 5.10.272 · 7.3 → 7.3 · 4.4 至 5.4 → 上游已終止維護

兩個 kfree，和另一顆還在讀的 CPU

Atlas 對機制的描述只有一句，說核心「then freed them immediately when the connection went away, while another CPU could still be reading them」。句子裡的「them」指什麼，要看 commit 標題才清楚：「ipv4: free inet_opt and ireq_opt after an RCU grace period」。合理的讀法是，被釋放的是 inet_opt 與 ireq_opt 這兩塊。連線結束時核心立刻把它們還回去；另一顆 CPU 如果剛好還拿著指標在讀，讀到的就是已經被釋放的記憶體。這是 use-after-free 的字面意思。

修補的形狀跟標題一致。Atlas 說這個修補把兩個普通的 kfree() 呼叫改成 kfree_rcu()，並寫「The upstream fix is a four-line change」。RCU 的一般語意是：釋放被延後，等到釋放當下已經在讀的人都離開之後才真正發生。這是 RCU 本身的定義，不是這份來源的新資訊；放在這裡，只是說明為什麼把 kfree 換成 kfree_rcu 就能關掉那個視窗。

影響面是另一回事。按 Atlas 的整理，這個洞可由遠端、不需認證的對端觸達；核心 CNA 描述的後果是核心 heap 資訊洩漏、記憶體損毀或當機，弱點類型欄沒有填 CWE。利用程式碼沒有公開：Atlas 說 Anthropic 沒有發布它。所以現在公開可讀的，是時間、宣稱與修補本身，不是可以照做的步驟。

MPTCP 為什麼會進到標題裡，是這個故事裡最容易讀歪的一段。gslin 的文章寫「這次的洞是 Linux 處理 MPTCP 的 Use-after-free 問題」，但同一頁的讀者留言指出「是IPv4 TCP的問題，MPTCP關了問題還是在」。Go Security Team 的公告寫「the underlying bug is not specific to MPTCP」，CloudLinux 寫「The bug itself is in ordinary TCP, so those servers still need the fix.」三個說法一致：漏洞在一般的 IPv4 TCP，MPTCP 是 Anthropic 展示的那條利用所需要的前提。

這三個一致的說法算不算互相印證，要打折。它們讀的是同一批公開資訊，不是各自做了實驗，所以我只把它當成「來源一致」，不當成「獨立驗證」。要說「沒有 MPTCP listener 也能利用」，目前沒有任何人公開示範；Go 團隊的措辭也只到「不專屬於 MPTCP」為止。

gslin 的文章本身就是一個時間點。它發在 11 月 1 日，比 Atlas 的 10 月 31 日傍晚快照晚一天，標題把它歸為 MPTCP 的洞，內文說後來發現 Go 預設開著 MPTCP listener，影響面比原先想的大，給的緩解是關掉 MPTCP 並重新啟動用到它的 daemon。同一頁的留言則把前提拉回來：問題在 IPv4 TCP，關掉 MPTCP 並沒有讓漏洞消失。一篇中文短文加一則留言，剛好呈現了這件事的資訊是怎麼被逐步修正的：先看到最顯眼的前提，再被更完整的資料補上。

發行版的落差：二十天之後

先逐家看 Atlas 在 10 月 31 日記下的狀態。Debian 已修：bookworm 的 6.1.190-1 與 linux-6.12 的 6.12.113-1~deb12u1，Atlas 附的 advisory 編號是 DLA-4841-1 與 DLA-4850-1。Oracle 的 UEK errata 在 10 月 16 日給了 Oracle Linux 7 到 10。Amazon Linux 在 10 月 29 日修好 AL2023 的 kernel6.12，10 月 30 日補齊其餘核心；Amazon 自己把它評為 Important、CVSS 3.1 8.1。SUSE 的 15 SP4、SP5、SP6 LTSS 核心已修，15 SP7 進行中。

沒修的是 Ubuntu 與 RHEL。Atlas 說 Ubuntu 把 linux 套件在每個版本都列為 Vulnerable；RHEL 8、9、10 與 OpenShift Container Platform 4、5 列為受影響，沒有修補。AlmaLinux 10 月 30 日把修好的核心放進 testing 倉，領先 RHEL，但還沒進正式倉。Atlas 的結論只有一句：「Ubuntu and RHEL haven't shipped a fixed kernel yet.」

gslin 在 11 月 1 日自己去查，說 Ubuntu 的頁面「全部都還是標 work in progress」。這兩個人看的是同一份 tracker，所以是同一個事實被讀了兩次，不是兩個獨立證據；它能補的只是日期，狀態到 11 月 1 日還沒變。下面把這些日期放到同一條軸上。拖動截止日，看每一條線在那一天有沒有修補；Debian 與 SUSE 的來源沒有給日期，圖上只用問號標記，不假裝知道。

拖動截止日看各條線的修補狀態 · 11 條線 × 31 天

截止日 10 月 31 日

10 月 31 日：有日期可查的 5 條修補線都已出貨，另有 AlmaLinux 進了 testing。Ubuntu 與 RHEL 距上游首個穩定版修補（10 月 11 日）已 20 天無修補。Debian、SUSE 已修，但來源沒有日期。

照日期算，10 月 11 日到 10 月 31 日是二十天，這是算術，不是來源的說法。這二十天裡，上游在第四天把五條長期分支都出完；Oracle 在第五天給了 errata；Amazon 在第十八到十九天補齊。圖上 Ubuntu 與 RHEL 兩條紅色橫條，就是這段還在等的時間。

為什麼等？Atlas 與 CloudLinux 都沒有說 Red Hat 或 Canonical 的原因，我不猜。CloudLinux 的頁面倒是把下游依賴寫得很清楚：它的 CL9 與 CL10 用 AlmaLinux 的核心，修好的版本在 AlmaLinux 的 testing 倉，而「Red Hat hasn't released its own fix yet」；在 Ubuntu 22.04 上則是「Canonical hasn't released its fix yet」，KernelCare livepatch 寫的是「in preparation」。合理的推測是，所有建在 RHEL 或 Ubuntu 核心上的下游，都跟著這兩家一起等，上游修好之後，瓶頸在發行版這一層。

對讀者來說，這張圖最直接的用途是分組。跑 Debian、Oracle Linux、Amazon Linux 的機器，來源裡已經有可裝的修補，剩下的是排進維護窗口、重開機。跑 SUSE 的要看自己是哪個版本：Atlas 只說 15 SP4 到 SP6 的 LTSS 已修、15 SP7 進行中，其他 SUSE 版本它沒有列。跑 AlmaLinux 的可以從 testing 倉先拿到修好的核心，但那不是正式倉。真正沒有選項的是 Ubuntu 與 RHEL 這兩組，只能靠下一節的暫時做法撐著。

9.8 是誰打的分數

核心自己的 CNA 給了 CVSS 3.1 9.8，Critical。其他人不一定同意：Atlas 說 Oracle、Amazon、SUSE 與 Ubuntu 的評分比較低，Amazon 的數字是 Important、8.1。Red Hat 的軌跡更值得看。Atlas 寫 10 月 30 日 Red Hat 把它從 Important（8.1）調到 Critical（9.8），並發布 RHSB-2026-016；我讀到的 Red Hat 頁面只寫「rated with a severity impact of Critical」，沒有提到從哪裡調來，所以「調高」這個動作目前只有 Atlas 一個來源。

9.8 和 8.1 的差距本身也有資訊。依 CVSS 3.1 的公式，同樣的向量裡只要把攻擊複雜度從低改成高，9.8 就會變成 8.1；合理的推測是，Red Hat 調分前後，以及 Amazon 與核心 CNA 之間的分歧，爭的就是這個欄位，也就是利用這個 race 到底難不難。Atlas 只給了核心 CNA 的向量字串，其中 AC:L 是低攻擊複雜度；Oracle、Amazon 與調分前的 Red Hat 用的是哪個向量，三份來源都沒給，所以他們是否改了這個欄位，只是從數字反推的猜測。這也說明了為什麼 Anthropic 的宣稱重要：它直接回答的正是「難不難」，而這個回答目前只有一方說過。

評級高低和修補進度之間，看不出簡單的對應。Atlas 說 Oracle、Amazon、SUSE 與 Ubuntu 都評得比 9.8 低，其中 Oracle 與 Amazon 已經出貨，SUSE 部分出貨，Ubuntu 卻一個版本都還沒有。反過來，評為 Critical 的 Red Hat 同樣沒有。換句話說，分數低不代表修得快，分數高也不代表修得慢；各家出貨的時間，看來取決於各自的核心維護流程，而不是這個數字。後半句是我的推測，來源沒有談到流程。

把當時發生的事排在一起：10 月 27 日，Anthropic 的 Frontier Red Team 描述了一個遠端 root exploit，Atlas 的說法是 Claude 在它們的實驗室裡寫成的；10 月 29 日，Go Security Team 發公告；10 月 30 日，Red Hat 調分。三件事各隔一兩天。來源沒有說 Red Hat 是因為前兩件事才調的，我也不下這個因果。能說的只是先後：嚴重度被改寫，發生在有人公開說自己能利用之後。

Anthropic 宣稱的內容要分開看。Atlas 寫這個利用是 Claude「after initial prompting」寫成的，並寫「it takes 48 minutes to leak a kernel pointer and another five minutes」；Anthropic 自己的研究頁面也有「it takes 48 minutes to leak a kernel pointer」這句。但後者正是 Atlas 的出處，所以算同一個來源。利用程式沒有公開，沒有人能照著重現。CloudLinux 說它的核心團隊「couldn't reproduce」Anthropic 宣稱的利用，同一頁也說沒有在野利用的回報。

「無法重現」不等於「宣稱是假的」。合理的推測是，在利用沒有公開的情況下，別人無從重現；CloudLinux 的說法最多只能說明「這個宣稱目前沒有第二個人驗證過」，說不出更多。同樣地，Anthropic 的數字描述的是它自己的實驗室條件，換成一台設定不同的機器會怎樣，來源沒有講。

公開面上，Atlas 說到 10 月 31 日傍晚（CDT 下午五點十五分），有 36 個 GitHub repository 提到這個 CVE，其中至少六個帶有 race trigger 或 PoC；CVE 不在 CISA 的 Known Exploited Vulnerabilities 目錄裡，NVD 的狀態是 Received，還沒有自己的分析。這些都是會變的數字，也只有 Atlas 一個來源，讀的時候請當成 10 月 31 日傍晚的快照。

Go 這一段把 MPTCP 前提從冷門變成常態。Go Security Team 寫「As of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux.」gslin 看到這一點後說「後來發現 Go 這邊預設開啟，就麻煩多了」。Go 團隊同時表示，現在就考慮改動 Go 本身是「premature to consider making any changes to Go」，也就是預設暫時不會變。下面這張表把上面這些說法逐條標上：誰說的、有沒有第二個來源、我怎麼分類。

說法	誰說的	其他來源怎麼說	本文的分類
CVSS 3.1 9.8，Critical	核心 CNA（經 Atlas 轉述）	Red Hat 頁面寫 Critical；Atlas 稱 Oracle、Amazon、SUSE、Ubuntu 評得較低，Amazon 為 8.1	各家評級不同
Claude 寫出可用的遠端 root exploit	Anthropic（經 Atlas 轉述）	CloudLinux 稱 couldn't reproduce；利用程式未公開	廠商宣稱，未獨立重現
48 分鐘洩漏核心指標，再加約五分鐘	Anthropic，Atlas 轉述同一出處	沒有獨立量測	廠商宣稱
Go 1.24 起預設為 listen socket 開 MPTCP	Go Security Team	gslin 引用同一份公告	一手來源
漏洞不專屬於 MPTCP	Go 團隊、CloudLinux、讀者留言	我的判斷：三者讀的是同一批公開資訊；示範的利用仍需 MPTCP listener	來源一致，非獨立驗證
Red Hat 在 10 月 30 日由 8.1 調到 9.8	Atlas	Red Hat 頁面只寫 Critical，未提調分	單一來源
未列入 CISA KEV；36 個 repo 提到此 CVE	Atlas，10 月 31 日 5:15 PM CDT	無	單一來源，會過期

修補程式到之前：四種做法各擋住什麼

第一種是正解：升級核心並重開機。CloudLinux 的說法是「The fix is the kernel update or livepatch for your version.」升級後要重開機才會真的跑新核心，Atlas 的檢查清單裡也有 needs-restarting -r。問題只在前一節：Ubuntu 與 RHEL 在 10 月 31 日還沒有東西可裝。

第二種是在網路層丟掉帶 IP options 的 IPv4 TCP 封包。Atlas 與 Red Hat 都給了 nftables 規則，Red Hat 的核心條件是 ip protocol tcp ip hdrlength > 5 counter drop。兩邊對限制的措辭都很直接：Atlas 寫「We haven't tested it against an exploit, and it doesn't fix the kernel.」，Red Hat 說規則「is not a substitute for patching」。Red Hat 也建議先在非 production 環境測試，核心更新後再把規則移除。

第三種是把 MPTCP 關掉。gslin 的說法是目前給的 mitigation 就是關掉 MPTCP，再重新啟動有使用 MPTCP 的 daemon，Atlas 的指令註解是「listeners opened earlier stay MPTCP: restart their services」。這一步拿掉的是 Anthropic 展示的利用所需要的前提，漏洞還在，讀者留言那句「MPTCP關了問題還是在」講的就是這件事。CloudLinux 在它預設就關著 MPTCP 的 CL8、9、10 上也寫「The setting doesn't remove the flaw.」

第四種專門給 Go 程式：用 GODEBUG=multipathtcp=0，或在 go.mod 加上 godebug 設定。Go 團隊自己把它叫做「a fragile mitigation」，理由是「Accidentally leaving a single MPTCP listener exposed will still leave a system vulnerable.」程式裡明確呼叫 SetMultipathTCP 的地方還會蓋掉 GODEBUG。下面的選擇器把四種做法並排，點哪一種就看它實際擋掉什麼、來源怎麼限制它。

點選做法，看它擋掉什麼 · 4 種做法

升級核心並重開機 nftables 丟棄 IP options 關閉 net.mptcp.enabled Go 程式設 GODEBUG

升級核心並重開機

改掉漏洞本身

是，改的是核心程式碼（升級或 livepatch）

實際擋掉的

整個漏洞，不限於 MPTCP 路徑

來源怎麼說

CloudLinux：「The fix is the kernel update or livepatch for your version.」

限制

要等你的發行版出貨；截至 10 月 31 日，Ubuntu 與 RHEL 都還沒有。

要知道自己現在站在哪，Atlas 列了幾個檢查指令，核心版本與重開機狀態一組，MPTCP 狀態一組：

# 核心版本與是否需要重開機
uname -r
uname -v
dpkg -l 'linux-image*'
rpm -q kernel
needs-restarting -r

# 有沒有 MPTCP listener、MPTCP 是否開啟
ss -Mlnp
sysctl net.mptcp.enabled

Atlas 也提到，容器和 Kubernetes 節點同樣在範圍內，因為容器與主機共用同一個核心；所以只改 image 沒有用，要處理的是節點。Docker 可以對單一容器設 --sysctl net.mptcp.enabled=0，Atlas 說這同樣只拿掉前提，不修漏洞。

對還在等修補的 Ubuntu 與 RHEL 機器，一個合理的順序是先用 ss -Mlnp 弄清楚哪些服務開著 MPTCP listener，因為 Anthropic 展示的利用要的是它；再決定要不要在邊界加上丟棄 IP options 的規則，並接受 Atlas 與 Red Hat 都說了的限制，也就是它降低暴露、不修核心。Go 服務特別容易漏，因為 listener 是語言執行環境預設開的，不是工程師自己選的。這個順序是我從來源的限制條件推出來的建議，不是哪一家的官方指引。

這篇有一個結構上的弱點要講明：日期與發行版狀態的主幹是 Atlas 一頁。我另外對照了 Go Security Team、Red Hat、CloudLinux、Anthropic 的頁面與 gslin 的文章，它們互相對得上的地方，是 Go 預設開 MPTCP、Red Hat 評 Critical、Ubuntu 與 RHEL 尚無修補這幾項；上游每個版本的出貨日期、Oracle 與 Amazon 的日期，則沒有第二份獨立來源逐條對過。想拿去做維運決策的人，應該直接開發行版自己的 tracker 確認。

還有幾件事沒有答案：IPv6 那個「first issue」之外是否另有問題；Anthropic 的利用是否有第二個人能重現；Ubuntu 與 RHEL 會在哪一天出貨。三個答案都不在目前的來源裡，這篇的快照是 10 月 31 日傍晚到 11 月 1 日，之後的狀態以各家 tracker 為準。

現況：修補在上游放了兩週以上，缺的是你那條發行版線上的核心和一次重開機；先查 uname -r 對照發行版 tracker，別把關掉 MPTCP 當成處理完畢。