返回

2026/11/04

CVE-2026-98432：Linux TCP 釋放後使用漏洞、AI 協助透過 MPTCP 遠端取得 root，以及企業 Linux 防禦對策

Linux IPv4 TCP 處理中的競爭條件、已示範的 MPTCP 遠端取得 root，以及 RHEL、Ubuntu、Oracle Linux 與 Debian 的供應商修正與緩解措施。

資訊查核日期：2026 年 11 月 3 日 | LOGIQ 技術分析

2026 年 10 月，Linux 核心的 IPv4 TCP 連線處理被揭露存在一個釋放後使用（use-after-free，UAF）漏洞 CVE-2026-98432。Linux 核心 CVE 團隊於 10 月 15 日發布通告。10 月 27 日，Anthropic 公布其一款尚未發表的內部研究模型，成功對一台設有 MPTCP（Multipath TCP）監聽端的 Linux 伺服器，在未經認證的情況下以 root 權限遠端執行指令。關鍵在於，不應將這次特定的攻擊條件，與影響一般 IPv4 TCP 服務的更廣泛漏洞及阻斷服務風險混為一談。

重點摘要

  • 此缺陷是一般 IPv4 TCP 連線請求處理中的競爭條件，自 Linux 4.4 起即存在。漏洞本身並不需要 MPTCP。
  • Anthropic 的遠端取得 root 示範針對的是設有 MPTCP 監聽端的伺服器；其他 TCP 服務仍面臨當機、阻斷服務與記憶體毀損的風險。
  • Red Hat 將此問題評為 Critical（CVSS v3.1 9.8），並於 11 月 1 日為 RHEL 8、9 和 10 發布修正核心。截至 11 月 3 日，Ubuntu 的修正仍在進行中。
  • 請安裝供應商核准的修正核心、重新開機，並確認正在執行的核心版本。緩解措施可降低曝險，但無法取代修補程式。

競爭條件發生在哪裡

此問題涉及 IPv4 TCP 三向交握。請求 socket 所持有的 IP 選項（ireq->ireq_opt）在 tcp_v4_syn_recv_sock() 執行期間，可能未經複製就被轉移到子 socket 的 inet_opt。如果另一顆 CPU 正在處理重傳的 SYN 並建構 SYN/ACK，而此時子 socket 遭到銷毀，這段選項記憶體就可能在仍被使用時遭到釋放。之後 ip_options_build() 等函式再存取它時，便可能觸發 UAF。

透過 net.ipv4.tcp_migrate_req=1 或 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 進行請求 socket 遷移時，也存在相關的競爭條件，此時原始與複製的請求 socket 之間可能共用選項資料。有漏洞的行為可追溯至 Linux 4.4，但實際曝險程度必須依各供應商的核心（包括向後移植的修改）個別評估。

上游修正提交 e3f33b0a1d89（”ipv4: free inet_opt and ireq_opt after an RCU grace period”）將 inet_sock_destruct() 與 tcp_v4_reqsk_destructor() 中的立即釋放，改為透過 kfree_rcu() 進行 RCU 延遲釋放。Linux CVE 通告指出，修正已納入核心版本 6.12.113、6.18.56、7.2.10 及 7.3-rc7。最初的 IPv6 路徑並不是同一個漏洞，不過一條涉及 CALIPSO 的 IPv6 遷移路徑已由另一個修補程式處理。

不要把已示範的遠端 root 存取與一般曝險混為一談

Anthropic 的概念驗證針對設有 MPTCP 監聽端的伺服器，結合了核心位址資訊洩漏與控制流程劫持。根據報告，該實驗約花 48 分鐘取得資訊洩漏，再花約五分鐘達成指令執行。由於競爭失敗只會讓交握失敗而不會使系統當機，攻擊者可以不斷重試。然而，底層的 UAF 位於一般 IPv4 TCP 連線請求處理中，並非僅存在於 MPTCP 程式碼。

同樣的遠端取得 root 攻擊手法，尚未在所有不使用 MPTCP 的傳統 TCP 服務上獲得證實。儘管如此，認為停用 MPTCP 就能讓系統完全安全也是錯誤的。Red Hat 表示 MPTCP 並非必要條件，停用 MPTCP（預設值）的系統仍受影響，並警告標準 IPv4 TCP 服務可能遭受未經認證的遠端當機、阻斷服務與記憶體毀損。

主要供應商評估：嚴重程度與修正狀態

以下為 2026 年 11 月 3 日查核時的狀態。供應商頁面會變動，採取行動前務必確認最新內容。

供應商嚴重程度修正狀態
Red HatCritical，CVSS v3.1 9.811 月 1 日發布修正核心：RHEL 8（RHSA-2026:93414；NFV 用 kernel-rt 為 RHSA-2026:93415）、RHEL 9（RHSA-2026:93412）、RHEL 10（RHSA-2026:93413）。RHEL 9 kernel-rt 與 OpenShift（RHCOS）仍列為 Affected。RHEL 6 與 7 不受影響。
Ubuntu優先等級 High；CVSS 9.826.10、26.04、24.04 與 22.04 的 linux：Vulnerable，work in progress。20.04、18.04 與 16.04：Vulnerable。尚未發布修正套件。
Oracle LinuxImportant；暫定 CVSS 8.1OL7 至 OL10 的 UEK 勘誤（ELSA-2026-500397、-500398、-500399），日期為 10 月 16 日。OL8（ELSA-2026-93414）與 OL10（ELSA-2026-93413）的 RHCK 勘誤，日期為 11 月 2 日；OL9 尚未列出 RHCK 勘誤。
Debian（Security Tracker）已修正於 bookworm 6.1.190-1（DLA-4841-1）、bookworm linux-6.12 6.12.113-1~deb12u1（DLA-4850-1）及 trixie 6.12.113-1（DSA-6568-1）；forky 與 sid 已修正。

Red Hat（評估於 10 月 30 日修訂；公告最後更新於 11 月 2 日）。官方 CVE 頁面將此問題評為 Critical，CVSS v3.1 9.8，原因是未經認證的遠端攻擊者可透過一般 IPv4 TCP 流量毀損核心記憶體或使系統當機。RHEL 8、9、10 與 OpenShift 列為受影響；RHEL 7 核心因不含相關程式碼而列為不受影響。自 11 月 1 日起，Red Hat 的 CVE 資料列出修正核心：kernel-4.18.0-553.182.1.el8_10（RHEL 8）、kernel-5.14.0-687.64.1.el9_8（RHEL 9）及 kernel-6.12.0-211.72.1.el10_2（RHEL 10）。安全公告 RHSB-2026-016 仍標示為進行中，緩解程序請以該公告為準。請勿將 5.9 或 8.1 等較舊的二手來源分數當作 Red Hat 目前的評估。

Ubuntu（官方表格最後更新於 10 月 30 日）。CVE 的 CVSS 為 9.8，Ubuntu 自身的優先等級則為 High。Ubuntu 26.10、26.04、24.04 與 22.04 的標準 linux 套件標示為「Vulnerable, work in progress」，頁面上並列出預定的修正版本；20.04 則標示為 Vulnerable 等狀態。AWS、Azure、HWE、RT 等其他核心版本必須個別評估。「work in progress」並不代表修正已經發布。

Oracle Linux。Oracle 自身的評估為 Important，暫定 CVSS 分數為 8.1。OL7、OL8、OL9 與 OL10 的 UEK 勘誤日期為 10 月 16 日，OL8 與 OL10 的 RHCK 勘誤則於 11 月 2 日跟進。UEK 中的修正不能直接推論至 RHCK 或所有次要版本；請依實際安裝的核心與確切的勘誤進行評估。

Debian。官方 Security Tracker 將 bookworm-security 6.1.190-1 與 trixie-security 6.12.113-1 等標示為已修正。請同時確認已安裝的套件版本，以及重新開機後正在執行的核心。

由於各發行版的組態與修正不同，CNA 與各供應商的 CVSS 結果可能不一致，評估也可能變動。請務必記錄查核日期，並連結至各官方來源。

防禦措施：緩解措施無法取代修補程式

第一優先是安裝供應商核准的修正核心，並在重新開機後確認正在執行的版本。若尚無修正可用，可考慮關閉不必要的對外 TCP 服務、限制允許的來源網路，並優先監控對外曝露的主機。

Red Hat 的公告描述了一種 nftables 緩解方式，會丟棄 IPv4 標頭中帶有 IP 選項的傳入 IPv4 TCP 封包：

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

這並非完整的防護，可能影響依賴 IP 選項的工作負載，部署前必須測試對業務流量的影響。TCP 標頭中的一般 TCP 選項仍會被允許；這並不是封鎖 TCP Options 欄位。在 OpenShift 上，節點層級的規則不會過濾叢集網路內 pod 之間的流量，因此在網路邊界進行過濾格外重要。修正核心開始執行後，請移除此 table。

小提示：修補後，請將 uname -r 的輸出與供應商勘誤中的修正版本比對，並將該輸出與變更紀錄一併保存。已安裝但尚未開機載入的套件，並不能消除此漏洞。

在 Linux 上，Go 1.24 及更新版本的 Go net 套件預設會為監聽端啟用 MPTCP。Go 團隊說明可用 GODEBUG=multipathtcp=0 停用（也可在 go.mod 中以 godebug 行設定）。變更預設值的提案仍在討論中，Go 維護者也指出，真正的修正是已修補的核心。此設定可降低 Anthropic 所示範、依賴 MPTCP 的攻擊路徑的曝險，但無法修正核心 UAF 本身。請逐一檢視各服務的 MPTCP 使用情況。

LOGIQ 的觀點

企業 Linux 維運無法僅憑公開的 CVSS 分數或 uname -r 判斷是否安全。必須綜合評估作業系統版本、核心系列（例如 UEK 與 RHCK）、套件版本、目前開機載入的核心、網路曝露狀況、MPTCP 設定、供應商勘誤以及重新開機的證據。請追蹤從影響評估、驗證到部署與維運監控的完整流程。

在供應商修正尚未推出時，請記錄暫時性緩解措施下的剩餘風險，並在修補程式推出後重新評估這些緩解措施。隨著 AI 提高漏洞的實際可利用性，企業維運必須涵蓋完整的生命週期：偵測、驗證、修補，以及正常運作的證據。

主要來源與參考資料