Linux IPv4 TCP 握手釋放後使用漏洞 CVE-2026-98432 評分為 CVSS 9.8

#Overview

Linux's stable kernels shipped a fix on October 11 and 15, 2026 for CVE-2026-98432, a use-after-free in the IPv4 TCP handshake that a remote, unauthenticated peer can reach. The kernel's own CVE Numbering Authority (CNA) scores it CVSS 3.1 9.8, Critical. The fixed releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, and 7.3, and the bug goes back to Linux 4.4. The upstream fix is a four-line change, but most servers run a distribution's kernel, and as of 5:15 PM CDT, October 31, Ubuntu's tracker still reads "Vulnerable" for its kernel on every release, and Red Hat, which now rates the bug Critical too, lists RHEL 8, 9, and 10 as affected with no fix.

Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials. Go programs open those listeners by default, per the Go Security Team. See the timeline.

#Key facts

Field	Detail
CVE	CVE-2026-98432, "ipv4: free inet_opt and ireq_opt after an RCU grace period," issued by the Linux kernel CNA
Severity	Critical, CVSS 3.1 9.8 (`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`), the kernel CNA's score. Red Hat also rates it Critical, CVSS 3.1 9.8, raised from Important (8.1) on October 30. SUSE rates it important, Ubuntu rates it High, and Oracle and Amazon rate it Important with CVSS 3.1 8.1.
Weakness	Use-after-free of IPv4 option data during the TCP handshake (the record lists no CWE)
Impact	Per the CNA's scoring notes: kernel heap contents disclosed to the remote peer, kernel memory corruption, or a crash. Red Hat's bulletin: a remote, unauthenticated attacker "could exploit a race condition during TCP connection request processing to trigger remote code execution."
Fixed in	7.2.10 and 6.18.56 (Oct 11) · 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 (Oct 15) · 7.3 (Oct 18)
No fix yet	Ubuntu (every release) and Red Hat Enterprise Linux (RHEL) 8, 9, and 10, as of 5:15 PM CDT, October 31. AlmaLinux's fixed kernels are still in testing. Upstream branches that reached end-of-life before 5.10 get no fix.
Proof of concept	Anthropic says Claude built a remote root exploit for servers with a multipath TCP listener. It hasn't published the exploit.
CVE records	Published on cve.org on October 15. NVD lists it as "Received," with no analysis of its own, as of 5:15 PM CDT, October 31.
Credit	Reported by Xinyang Ge of Anthropic. Fixed by Eric Dumazet and reviewed by Kuniyuki Iwashima, per the fix commit.

#Who is affected

Any Linux kernel from 4.4 on that lacks the fix, whether it serves the network directly or hosts containers: a container runs on the host's kernel, so a new image doesn't change anything. IPv6 connections aren't affected by the main issue; the commit says "IPv6 is not affected by the first issue."

Release line	Status on Oct 31, 2026	Fixed in	Released
7.3	Mainline	7.3 (from 7.3-rc7)	Oct 18, 2026
7.2	Stable	7.2.10	Oct 11, 2026
6.18	Longterm	6.18.56	Oct 11, 2026
6.12	Longterm	6.12.113	Oct 15, 2026
6.6	Longterm	6.6.159	Oct 15, 2026
6.1	Longterm	6.1.190	Oct 15, 2026
5.15	Longterm	5.15.223	2026年10月15日
5.10	長期	5.10.272	2026年10月15日
4.4 – 5.4	上游已終止支援	僅發行版提供修補程式	—

#發行版狀態

發行版核心會以各自的版本號附帶回移的修補程式，因此應查閲追蹤頁面，而非上游版本號。截至10月31日下午5:15 CDT：

Ubuntu：追蹤頁面顯示，linux 套件在所有版本中均標示為「有漏洞」。26.10、26.04、24.04 和 22.04 的 7.3.0-10.10、7.0.0-43.43、6.8.0-149.149 和 5.15.0-203.213 另註明「正在處理」；20.04、18.04 和 16.04 則只標示為「有漏洞」。許多雲端及硬件支援核心也有相同標示，而且 Ubuntu 尚未發布安全公告。
Red Hat：自10月30日起，評級為嚴重，CVSS 3.1 9.8。RHEL 8、9 和 10，以及 OpenShift Container Platform 4 和 5 均列為受影響，尚無修補程式；RHEL 6 和 7 不受影響（CVE 頁面）。其公告 RHSB-2026-016 表示「Red Hat 正加快發布修補程式」，提供 nftables 緩解措施（下文比較），並指出任何依賴 RHEL 核心的產品，包括 RHEL CoreOS，「亦可能受影響」。
AlmaLinux：AlmaLinux 8、9 和 10 的修補核心（kernel-4.18.0-553.180.2.el8_10、kernel-5.14.0-687.61.2.el9_8 和 kernel-6.12.0-211.69.2.el10_2）自10月30日起已在其測試套件庫提供，早於 RHEL。AlmaLinux 將在社羣測試後把它們移至正式套件庫，目前其勘誤資料尚未列出這些核心（公告）。
Debian：已在 12「bookworm」（6.1.190-1、DLA-4841-1，以及 linux-6.12 6.12.113-1~deb12u1、DLA-4850-1）、13「trixie」（6.12.113-1、DSA-6568-1）及 unstable 中修補（追蹤頁面）。
SUSE：評級為重要。SUSE Linux Enterprise Server 16.0（kernel-default 6.12.0-160000.40.1）以及 15 SP4、SP5 和 SP6 LTSS 核心已修補；15 SP7 正在處理。openSUSE Leap 16.0 已修補，Leap 15.6 則列為受影響（CVE 頁面）。
Oracle Linux：評級為重要，CVSS 3.1 8.1。Oracle Linux 7、8、9 和 10 的 Unbreakable Enterprise Kernel (UEK) 勘誤於10月16日發布：ELSA-2026-500397、ELSA-2026-500398 和 ELSA-2026-500399（CVE 頁面）。頁面只列出 UEK 核心。
Amazon Linux：評級為重要，CVSS 3.1 8.1，所有核心均已修補。Amazon Linux 2023 的預設 kernel（ALAS2023-2026-3365，10月30日）、kernel6.12（ALAS2023-2026-3335，10月29日）和 kernel6.18（ALAS2023-2026-3251，10月24日）均已修補。Amazon Linux 2 的核心 kernel（ALAS2-2026-4065），以及 5.4、5.10 和 5.15 Extras 核心（ALAS2KERNEL-5.4-2026-135、ALAS2KERNEL-5.10-2026-137 和 ALAS2KERNEL-5.15-2026-120）亦已修補，全部於10月30日發布（CVE 頁面）。

#漏洞運作原理

Linux 伺服器接受 TCP 連線時，核心會以輕量級的「請求 socket」追蹤尚未完成的握手，並在握手完成後建立完整 socket。如果連線對端的 IPv4 標頭帶有選項，核心會保留這些選項，以便在回覆中回送。漏洞在於：核心把已儲存的選項從請求 socket 移交至新連線時，沒有先複製選項；連線中斷後便立即釋放它們，但此時另一個 CPU 仍可能正在讀取這些選項，以建立握手回覆。讀取已釋放的核心記憶體，就是 use-after-free 漏洞。

對等端無須登入，整個過程都在核心處理握手時發生，早於任何應用程式碼執行。CNA 的評分説明指出，過時資料可能會將核心堆積區記憶體洩漏給對等端、令核心寫入越界，或令機器當機。Anthropic 表示，競爭落敗「只會令握手失敗，不會令整個系統當機，因此有決心的攻擊者可以無限次重試，直至成功」。

#修正方法

Eric Dumazet 的提交「ipv4：在 RCU 寬限期後釋放 inet_opt 和 ireq_opt」，將兩個普通的 kfree() 呼叫改為 kfree_rcu()；後者會等到所有讀取者都完成對該記憶體的存取後，才釋放記憶體。其他會替換這些選項的程式碼路徑早已採用這種做法。此提交亦修正了請求 socket 遷移時的相同問題（net.ipv4.tcp_migrate_req=1，或是 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 程式），並指出相關的 IPv6 情況「將於另一個修補程式中處理」。

torvalds/linux · e3f33b0 · Oct 1, 2026

net/ipv4/af_inet.c

新增 1 行，刪除 1 行

net/ipv4/tcp_ipv4.c

新增 1 行，刪除 1 行

修改 2 個檔案新增 2 行，刪除 2 行

#哪些伺服器會受影響

所有在受影響核心版本上接受 IPv4 TCP 連線的 Linux 主機：網頁伺服器、SSH、資料庫、負載平衡器及 Kubernetes 節點。CNA 的説明指出，有漏洞的程式路徑會「在 TCP 握手期間、應用程式驗證之前」執行。
優先留意設有多路徑 TCP (MPTCP) 監聽 socket 的主機。這是 Anthropic 的在研漏洞利用程式所需的配置：「設有多路徑 TCP 監聽 socket 的 Linux 伺服器。」Anthropic 未有説明這類監聽 socket 為何重要，而 CVE 記錄亦沒有提及 MPTCP。只有應用程式開啟 MPTCP socket，伺服器才會有這類監聽 socket；Go 程式預設會這樣做：Go Security Team 指出，「自 Go 1.24 起，Go 程式在 Linux 上預設會為監聽 socket 啟用 MPTCP。」這項預設設定沿用 go 行（位於程式的 go.mod 中），而且只適用於核心允許 MPTCP 的情況（net.mptcp.enabled = 1；我們檢查的 Debian 12 核心便是如此；AlmaLinux 表示其隨附版本的 MPTCP 為關閉狀態）。Go 團隊補充：「問題本身並非 MPTCP 專有。沒有 MPTCP 監聽 socket 的系統，亦可能受到類似攻擊。」檢查方法如下。

Red Hat 現在採用與 CNA 相同的評級。Red Hat 在 10 月 30 日將漏洞評級由「重要」（8.1）上調至「嚴重」（9.8），理由是「沒有網絡前置條件，而且可能導致嚴重的系統不穩定」。其公告指出：「接受傳入 TCP 連線的系統最直接暴露於風險之中。」

#如何檢查系統

#檢查核心

Compare the result with your distribution's status above, not with the upstream version. If the installed kernel is newer than the running one, the fix isn't active until you reboot. Run these on container hosts and Kubernetes nodes, not inside containers: a container reports the host's kernel. We ran them on a Debian 12 host and in a Rocky Linux 9 container.

#檢查多路徑 TCP 監聽 socket

ss -M 只會列出 MPTCP socket，因此結果為空即代表沒有 MPTCP 監聽 socket。單靠 net.mptcp.enabled = 1 並不會建立這類監聽 socket；應用程式必須開啟 MPTCP socket。我們在 Debian 12 容器中使用 iproute2 6.1 測試兩者；在該環境中，ss -Mlnp 列出一個測試用的 MPTCP 監聽 socket，並略過旁邊的普通 TCP 監聽 socket。10 月 31 日，該指令亦列出一個 Go HTTP 伺服器；其 go.mod 顯示 go 1.24，而以 go 1.23 建置的相同伺服器則沒有列出。

#如何修補

#更新核心並重新啟動

發佈修補版本後，請盡快安裝你所用發行版的修補版核心，然後重新啟動：核心更新要等裝置載入新核心後才會生效。容器主機和 Kubernetes 節點也要重新啟動。內置核心的設備和雲端映像檔則需要安裝供應商提供的更新。

Debian、SUSE Linux Enterprise Server 16.0 和 15 LTSS 版本、openSUSE Leap 16.0、Oracle Linux 的 UEK 核心，以及 Amazon Linux 2 和 2023 已推出修補程式。AlmaLinux 的修補程式則在測試套件庫中。截至 5:15 PM CDT, October 31，Ubuntu 和 RHEL 尚未推出修補程式。請留意上文連結的追蹤頁面。如果你使用自行編譯的核心，請升級至該核心系列的修補穩定版本。

#如果暫時無法修補

Red Hat 的公告和AlmaLinux現已發布 nftables 規則，用以丟棄帶有 IP 選項的輸入 IPv4 TCP 封包。Red Hat 表示，其規則「可降低受到此漏洞影響的風險，但無法完全防止漏洞被利用。」以下是 Atlas 的臨時建議，使用的規則與 AlmaLinux 相同，依據 CNA 的評分説明制定；該説明指出，攻擊對端會在 SYN 封包中加入 IPv4 Record Route 或 Timestamp 選項。TCP 流量幾乎從不會合法地帶有 IPv4 選項，因此丟棄含有這些選項的 TCP 封包不會造成任何影響：

ip hdrlength gt 5會匹配任何長於 20-byte 最低長度的 IPv4 標頭，只有選項才會令標頭超出此長度。此規則會在連線追蹤之前執行，不會影響 IPv6 或非 TCP 流量。我們在 Debian 12 容器中測試了此規則：它丟棄了帶有 Record Route 選項的 SYN 封包，而一般 TCP 連線仍可正常運作。我們未有使用漏洞利用程式測試此規則，而且它不會修補核心。規則會保留至重新啟動；若重新啟動後載入的是修補版核心，便沒有問題；使用 nft delete table ip cve_2026_98432 可移除規則。如果你的邊界防火牆可以丟棄帶有選項的 IPv4 封包，在防火牆上執行此操作便可保護其後的所有主機。

如果你使用 iptables 管理防火牆，以下規則可達到相同效果，並會在 raw 表中、連線追蹤之前執行：

u32匹配會讀取 IPv4 標頭長度欄位；數值介乎 6 至 15 表示標頭帶有選項。我們在 Debian 12 容器中使用 iptables 1.8.9 測試了此規則，並分別測試其 nf_tables 和 legacy 後端：它丟棄了傳送至主機及經主機路由的 Record Route SYN 封包，而一般 TCP 連線仍可正常運作。執行同一指令，並以 -D 取代 -I，即可移除規則；與 nft 規則一樣，它會保留至重新啟動。此規則需要核心的 xt_u32 模組；Debian 12、Ubuntu 22.04 和 24.04，以及 RHEL 8 的核心均包含此模組。RHEL 9 和 10 的核心及其重建版本則沒有包含，因此請在這些系統使用 nft 規則。

Red Hat 的規則掛接在 input；我們的規則掛接在 prerouting，因此也會丟棄主機轉送至容器的封包。10 月 31 日，我們使用兩組網絡命名空間進行測試。規則丟棄了在其中一組之間路由的 Record Route SYN 封包，但完全沒有處理在另一組之間橋接的封包，正如 AlmaLinux 的警告：「同一主機上容器之間的流量可能會繞過此規則。」AlmaLinux 亦表示，依賴 CIPSO 安全標籤的網絡不應使用此規則；這些標籤會透過 IPv4 選項傳送。

如果不使用多路徑 TCP，請將其停用。這樣便會移除 Anthropic 漏洞利用程式所需的設定，但不會修補漏洞。AlmaLinux 的操作步驟：

之後新建的 MPTCP socket 會失敗，而 Go 程式在啟動時會回退至純 TCP。這項設定按網絡命名空間劃分，每個新建的網絡命名空間預設都會啟用 MPTCP，因此除非也在容器內設定，否則容器仍會啟用 MPTCP（Docker：--sysctl net.mptcp.enabled=0）。我們於 10 月 31 日測試了相關步驟及 Docker 選項。只針對單一 Go 程式，在其環境中設定 GODEBUG=multipathtcp=0 便可關閉預設設定，但 Go Security Team 稱，逐個程式停用 MPTCP 是「脆弱的緩解措施」。

在可以安裝修補程式前，不要讓 MPTCP 監聽器暴露於互聯網，並將有此類監聽器的主機列為優先修補對象。

#時間線與漏洞利用狀況

所有時間均為 CDT (UTC−5)。

何時	事件
10 月 1 日 · 下午 5:12	Eric Dumazet 發佈修補程式，並註明通報者是 Anthropic 的 Xinyang Ge
10 月 5 日	修補程式合併至核心的網絡子樹
10 月 11 日	Linux 7.2.10 和 6.18.56 推出包含修補程式的版本；7.3-rc7 於當晚推出
10 月 15 日 · 上午 4:56–7:16	Linux 6.12.113、6.6.159、6.1.190、5.15.223 和 5.10.272 推出包含修補程式的版本；CVE 記錄於上午 7:08 發布
10 月 16 日	Oracle 發布包含修補程式的 UEK 勘誤，適用於 Oracle Linux 7 至 10
10 月 18 日	Linux 7.3 發布，並包含修補程式
10 月 24 日	Amazon Linux 2023 的 `kernel6.18` 套件已修補
10 月 27 日	Anthropic 的 Frontier Red Team 描述一個針對該漏洞的遠端 root 漏洞利用程式，由 Claude 在其實驗室中製作
10 月 29 日 · 下午 6:34	Go Security Team 表示，自 Go 1.24 起，Go 程式預設會開啟 MPTCP 監聽器
10 月 29 日	Ubuntu 仍將其核心版本列為易受攻擊；Amazon Linux 2023 的 `kernel6.12` 套件已修補；GitHub 上開始出現提及該 CVE 的儲存庫，其中一個於晚上 7:22 建立，描述一種競態條件觸發方式
10 月 30 日	AlmaLinux 將已修補的核心放入測試儲存庫；Red Hat 將評級上調至嚴重，並發布包含緩解措施的公告 RHSB-2026-016；Amazon Linux 修正其餘核心版本
10 月 31 日	36 個 GitHub 儲存庫提及該 CVE，其中至少六個描述競態條件觸發方式或概念驗證

漏洞利用狀況。Anthropic 表示，Claude「在初步提示後」編寫了漏洞利用程式；在有 multipath TCP 監聽器的伺服器上，它可以「以 root 身分執行任意命令，無需任何憑證或用戶互動」。Anthropic 又稱，在其概念驗證中，「洩漏核心指標需要 48 分鐘，之後再用五分鐘便可執行 shell 命令」。Anthropic 尚未發布該漏洞利用程式。其披露政策給予開發者 90 天時間修補，並在此後再等 45 天，Anthropic 才會討論公開公告以外的細節。Red Hat 的公告現時表示，該漏洞可被利用「以觸發遠端程式碼執行」。截至 10 月 31 日 CDT 下午 5:15，36 個 GitHub 儲存庫提及該 CVE。大部分儲存庫自稱是稽核或緩解工具，其中包括 Ansible 角色，以及適用於 AlmaLinux 和 Rocky Linux 的即時修補程式。至少六個儲存庫聲稱包含競態條件觸發方式，或針對釋放後使用漏洞的概念驗證；最早的一個於 10 月 29 日晚上 7:22 建立，最新的一個則於 10 月 31 日上午 11:04 建立。截至 10 月 31 日 CDT 下午 5:15，該 CVE 尚未列入 CISA 的已知遭利用漏洞目錄。我們沒有測試任何公開的概念驗證程式，也不會提供其連結。

#本文更新事項

以下任何一項有變動時，我們會修訂本文並標示為已更新：Ubuntu 或 Red Hat 推出已修補的核心，或 AlmaLinux 正式版發布；NVD 的分析；列入 KEV 名單或任何漏洞遭利用的報告；獨立的 IPv6 修正。

October 31, 5:15 PM CDT: Red Hat 於 October 30 將評級由 Important (8.1) 上調至 Critical (9.8)，並在公告 RHSB-2026-016 中發布緩解措施，因此我們更新了先前的評級及「沒有緩解措施」的説法。新增了 Go Security Team 的公告（Go 程式預設會開啟 MPTCP 監聽器）、AlmaLinux 正在測試的已修補核心、Amazon Linux 對其餘核心的修正、openSUSE Leap 16.0 的修正、停用 MPTCP 的步驟、以 iptables 編寫的臨時規則版本，以及該臨時規則在橋接式容器流量和 CIPSO 方面的限制。目前有 36 個 GitHub 存放庫提及此 CVE。Ubuntu、Debian、Oracle、NVD 的狀態及 KEV 均沒有變動，而 October 30 發布的穩定版核心未包含 IPv6 後續修補。
October 29, 8:00 PM CDT: 新增 Oracle Linux（其 UEK 核心自 October 16 起已修復）及 Amazon Linux（Amazon Linux 2023 的 6.12 和 6.18 核心已修復，其他核心則仍待修正）。目前有八個 GitHub 存放庫提及此 CVE，其中一個描述了觸發競態條件的方法。自 11:00 AM 起，Ubuntu、Red Hat、Debian、SUSE、NVD 及 KEV 均沒有變動，亦沒有更正任何內容。