CVE‑2026‑98432：Linux TCP 記憶體使用後自由漏洞與修補驗證

CVE-2026-98432 是 Linux 核心 IPv4 TCP 握手路徑中的一次使用已被釋放物件的錯誤。當兩個處理器同時處理相關的請求與子 socket，且兩者仍可參照同一個 IP 選項物件時，便會出現此缺陷。某一路徑可能立即釋放該物件，而另一路徑僅以 RCU 讀者保護，仍繼續使用它。結果是透過網路流量可達到的程式碼中出現一個舊的核心指標。

簡短的描述聽起來像熟悉的核心競態條件，但公開證據需要謹慎詮釋。CVE 記錄的 CVSS 3.1 分數為 9.8，代表可透過網路達成、未經身份驗證的最壞情境，對機密性、完整性與可用性均有高度影響。Red Hat 的產品分析則給予較低的 5.9 分，因為它將利用視為難以發生的競態條件，並在其支援的產品中以更保守的方式評估實際後果。另據 Anthropic 的 Frontier Red Team 在受控實驗室中報告，對一臺搭載多路徑 TCP 監聽器的 Linux 伺服器實現了可執行遠端 root 程式碼鏈。此結果是針對特定組態下可被利用的嚴重證據，並非證明每臺未打補丁的 Linux 伺服器、每個普通 TCP 監聽器或每個發行版建置都能以相同方式被攻陷。

防禦者應將這些說法視為互補。上游記錄指出一個危險的記憶體生命週期錯誤及其理論上最大的影響。發行版分數描述供應商已釋出的程式碼、設定、緩解措施以及預期的利用條件。研究利用示範了針對特定目標的具體路徑。三者皆不應被忽略，也不應被擴充套件超出其範疇。

實務回應直接：確認可被存取的 Linux TCP 服務，判斷實際執行的供應商核心版本，安裝供應商提供的已修補版本，重新啟動並保留證據以證明執行中的核心包含修正。公開研究專門驗證了 MPTCP 監聽器環境，因而暴露 MPTCP 監聽器的主機應立即受關注。即使未故意啟用 MPTCP，面向網際網路的閘道器、負載平衡器、Kubernetes 節點、VPN 端點、反向代理以及使用 Linux 網路的裝置也應迅速盤點。

關於 CVE-2026-98432 已確認的事項

權威技術描述來自 Linux 核心 CVE 程式與上游修補程式。此問題涉及與 TCP 請求 socket 相關聯的 IPv4 選項資料的所有權與回收。在 TCP 握手的伺服器端，核心會建立一個輕量級的請求 socket 以代表尚未完全連線的連結。當握手進行時，tcp_v4_syn_recv_sock() 將請求的 ireq_opt 指標以 inet_opt 方式轉移至新的子 socket。它並未複製該物件。

同時，另一個 CPU 可能處理與同一請求相關的重傳 SYN。第二條路徑可以透過 tcp_check_req() 傳送另一個 SYN‑ACK。tcp_v4_send_synack() 與 inet_csk_route_req() 等函式在 RCU 讀端關鍵區段內讀取請求的 IP 選項。後續輔助函式，包括 ip_build_and_send_pkt() 與 ip_options_build()，會取消參考選項物件中的欄位。Debian 安全追蹤器重現了上游說明，並將此問題對應至已修補的 Debian 核心套件。

生命週期不匹配是核心問題。讀取器表現得好像 RCU 保護了物件，但析構函式用普通 kfree() 釋放它。普通 kfree() 使分配可供重複使用，而不必等待現有 RCU 讀取器完成。若子 socket 在重傳 SYN 路徑仍在使用選項時被銷毀，第二個 CPU 可繼續讀取已不屬於該物件的記憶體。主要的上游修正將立即釋放替換為 kfree_rcu()，延遲回收直到 RCU 容忍期結束。

漏洞還有一個相關的請求遷移案例。若 net.ipv4.tcp_migrate_req=1 已啟用，或若 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 程式控制請求遷移，核心可能會複製一個請求 socket。舊的請求及其複本可暫時共用同一個選項物件。持有舊請求參考的 CPU 在複本被釋放時仍可使用該物件。因此，核心說明將 inet_sock_destruct() 與 tcp_v4_reqsk_destructor() 改為使用 RCU 感知的回收。

第一個問題僅適用於 IPv4 子 socket 路徑，因為對應的 IPv6 函式會複製選項，而非轉移相同指標。上游文字亦提到在 CALIPSO 存在時涉及 ipv6_opt 的 IPv6 請求遷移問題，並說明該條件單獨處理。這一區分很重要：說「IPv6 不受影響」太籠統，而說主要 IPv4 所有權轉移漏洞不適用於普通 IPv6 子建立路徑則是準確的。

此補丁已在上游合併為提交 e3f33b0a1d89，標題為「ipv4: free inet_opt and ireq_opt after an RCU grace period」。Ubuntu CVE page 識別相同的引入與修正提交，並獨立追蹤多個 Ubuntu 核心變種。這是證明通用核心版本檢查無法取代發行版特定狀態的有用證據。

尚未確立的事實

此處未引用任何權威來源證實該漏洞在公共網際網路上被廣泛利用。Anthropic 表示其研究人員能將此缺陷轉化為針對受控目標的遠端 root 指令執行，前提是存在 MPTCP 監聽器。這比僅僅證明崩潰更具說服力，應該影響緊急程度。然而，它仍未提供受影響 MPTCP 服務的實際普及率、普遍成功率或證明相同的利用鏈在不同核心版本、CPU 架構、分配器、硬化配置和網路路徑上保持不變。

公開資料也不證明任何大量 SYN 重傳即為利用。重傳 SYN 封包自然發生，原因包括封包遺失、非對稱路由、服務過載、客戶端重試行為以及中間裝置。利用競態條件可能產生異常模式，但必須與易受攻擊的主機、相關選項、核心症狀和時序相關聯。網路警報可優先調查；它無法證明核心內部發生了 use-after-free。

沒有單一的上游版本字串能準確標示所有供應商的核心。企業發行版常常回移安全修正，同時保留較舊的基礎版本。雲端供應商與裝置供應商可能會推出自己的核心構建。僅將uname -r與上游發布清單比較的掃描器可能產生偽陽性與偽陰性。可辯護的結論來自供應商公告、套件更新日誌、構建元資料、VEX說明，或直接確認相關修正提交已被回移。

最後，停用 MPTCP 並不會消除底層的 IPv4 生命週期錯誤。它移除在公開研究鏈中使用的精確監聽器配置，並能在不需要 MPTCP 的情況下實質減少即時曝露。上游技術說明涵蓋普通 IPv4 TCP 請求與子 socket 路徑，以及請求遷移。修補程式部署仍是持久的修正。

脆弱 TCP 路徑的工作原理

TCP 伺服器通常會接收 SYN，回覆 SYN‑ACK，並等待最後的 ACK。核心避免在第一個封包時就分配完整的已連線 socket，因為攻擊者可能利用此方式廉價耗盡資源。相反地，它會建立一個緊湊的請求 socket，存放足夠的狀態以驗證並完成握手。當 ACK 到達且連線被接受時，核心會建立完整的子 socket，並將選定的狀態移動或複製到其中。

IPv4 選項使這一過程變得複雜。IP 選項可攜帶影響路由或封包處理的元資料。核心會解析傳入資訊並儲存內部表示，以供後續回應建構。於受影響的路徑中，請求 socket 的 ireq_opt 指標成為子 socket 的 inet_opt 指標。此轉移避免了複製，但表示一個分配的生命週期跨越兩個 socket 物件之間的邊界。

同一連線組合的第二個 SYN 可能在握手狀態完全穩定前到達。重傳是 TCP 的正常行為。核心可能在另一個 CPU 上處理該 SYN，並使用原始請求 socket 建立 SYN‑ACK。由於 Linux 網路高度並行，子 socket 可以在另一個 CPU 仍在構建回覆時進一步進行拆除。請求路徑會取得 RCU 讀鎖，表示它讀取的資料必須在讀側關鍵區段結束前保持有效。

舊的析構行為違反了此期望。子 socket 並未攜帶會推遲其整體釋放的 SOCK_RCU_FREE 行為，且 inet_sock_destruct() 直接釋放 inet_opt。第二個 CPU 可能保留該指標並從已回到分配器的記憶體中讀取 optlen。之後的分配可能在該地址放置不相關的資料，導致讀取之間的值變化，或讓後續程式碼操作受攻擊者影響的內容。

Use‑after‑free 缺陷危險的原因在於其即時症狀取決於釋放的記憶體被什麼取代。過期的存取可能會讀取舊的位元組，看起來無害；亦可能碰到被毒化或未對映的記憶體而導致崩潰；又或讀到新的核心物件而洩露資料。若能充分掌控分配模式與時序，研究者可將這個過期參照轉化為更強大的讀、寫或控制流程原語。因此，該漏洞類別可導致從間歇性握手失敗、服務拒絕到執行程式碼等多種結果，但必須為特定目標證明具體結果。

請求遷移變體以不同的拓撲方式遵循相同的生命週期原則。Reuseport 允許多個 socket 共用一個監聽埠，而 BPF 可以參與選擇目標。當監聽器變更狀態時，請求遷移可能會移動待處理的連線。核心會複製請求狀態，產生一個視窗，在此期間兩個請求物件指向同一個選項配置。清除其中一個物件的指標並不保護已持有該參考的 CPU。若另一個物件的析構函式立即釋放共享配置，那個讀取器就會變成過期。

此補丁並未嘗試將所有操作序列化到單一全域鎖後。這會損害高頻網路路徑的可擴充套件性。相反地，它將回收機制與讀者已經使用的同步模型對齊。這正是 Read‑Copy Update 設計要解決的問題型別。

為何 RCU 改變安全邊界

Read-Copy Update 允許讀者以極低開銷存取共享資料，寫者則發布替代物並延遲釋放舊版本。讀者進入 RCU 讀端臨界區，取得指標，使用物件後離開。寫者可將物件從資料結構中移除，使新讀者找不到它，但必須等待一個寬限期（grace period）才可回收記憶體。寬限期確保所有可能看到舊指標的讀者都已結束。

Linux kernel 的 RCU 檔案 描述了移除與回收的核心分離。移除改變可達性。回收將儲存空間還給分配器。將兩個操作混合是常見的 use-after-free 錯誤來源。RCU 鎖不會在任意物件上放置引用計數，也不會直接使 kfree() 安全。相對的寫者必須使用 RCU-aware 機制，例如 call_rcu() 或 kfree_rcu()。

在 CVE-2026-98432 中，讀取路徑已經使用 RCU。修正使得析構函式遵守此協定。kfree_rcu() 會在寬限期後排程物件釋放，而非立即釋放。構建 SYN-ACK 的 CPU 可以完成對舊選項物件的讀取。後續讀者將不再取得它，且該分配在舊讀者離開後才可重複使用。

此設計保留了併發性。它不需要伺服器停止處理重傳、在握手構造周圍加大鎖，或為每次讀取複製選項物件。安全性屬性簡潔明確：對 RCU 讀者可見的物件在該讀者可能存取期間仍保持分配。

RCU 修正也說明瞭僅靠封包過濾無法成為完整解決方案。記憶體安全缺陷存在於物件生命週期管理。過濾可能使觸發條件更難觸及，停用不必要的功能可減少路徑集合。唯有正確的回收機制才能為每個合法與惡意封包在抵達程式碼時維持不變式。

調和 9.8 與 5.9 分數

CVE 記錄的 CVSS 3.1 向量為 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，產生 9.8。此向量假設網路攻擊者不需要帳號也不需要使用者互動，攻擊複雜度低，且成功利用可對機密性、完整性與可用性產生高影響。它表達了 CNA 對脆弱上游元件的基礎描述。

Ubuntu 顯示 9.8 的值，但也公佈了帶有攻擊前置條件的 CVSS 4.0 評估 8.3。CVSS 4.0 能表示不易對映於舊向量的先決條件。Ubuntu 的頁面將漏洞標示為高優先順序，並以套件為單位顯示狀態，而非將數值分數視為整體決策。

Red Hat 的 5.9 分數反映了不同的評估。Red Hat 以其產品、回溯、預設設定、緩解措施及可能後果為背景評估漏洞。其分析將競爭條件視為高複雜度，並強調可靠的安全影響可能是崩潰或服務拒絕，而記憶體破壞及更嚴重結果則取決於額外條件。較低的供應商分數並不意味上游錯誤不存在；它表示供應商不接受其所供產品的每一種最壞情境指標。

對於以不同形式散佈的開源元件，CVSS 之間的分歧很常見。相同的原始碼缺陷可能存在於兩個產品中，但透過不同的設定被暴露。某供應商可能預設啟用某功能，另一個則省略，第三個則帶有部分回溯，改變可達性。核心硬化、記憶體分配器行為、架構、編譯器選項及服務拓撲都可在不改變脆弱原始碼行的情況下影響利用開發。

在運營優先排序上，單一通用分數不如簡短的環境特定分析實用：

9.8 的分數有助於辨識潛在上限。5.9 的分數則有助於瞭解 Red Hat 的產品特定觀點。這兩個數值不應該覆蓋已經在實驗室中被利用的公開 MPTCP 目標的事實，且實驗室結果不應被轉化為大規模利用的說法。防禦者可以在保留上述區別的前提下，緊急採取行動。

Anthropic MPTCP 研究證明瞭什麼

Anthropic 10月27日的研究貼文 描述了一個遠端、零點選的 Linux 核心漏洞，針對具有 Multipath TCP 監聽器的伺服器。根據研究人員，該漏洞在兩個階段利用競爭引發的 use-after-free。第一階段取得核心指標並擊破核心地址空間佈局隨機化。第二階段將記憶體損毀轉化為控制流程劫持，最終以 root 身份執行攻擊者選定的指令。

團隊表示，其概念驗證大約需要 48 分鐘來披露核心指標，另外 5 分鐘即可完成指令執行。一次失敗嘗試可能會留下未完成的握手，而不必致使主機崩潰，允許重複嘗試。此行為之所以重要，是因為競爭條件漏洞往往在失敗成本低且可重試數量多時才變得實用。

該研究提供可信證據，顯示此漏洞可造成拒絕服務之外的影響。它亦告訴防禦者，哪些公開暴露應優先處理：對於易受攻擊的核心而言，未受信任的網路存取至已啟用 MPTCP 的監聽器。官方Linux MPTCP 檔案說明瞭 Multipath TCP 如何延伸普通 TCP，使連線可使用多個子流，同時保持與現有應用程式相容。Linux 發行版可能會提供 MPTCP 支援，但並非所有應用程式或服務都使用它，因此管理員需檢查執行時狀態與監聽器，而非僅根據套件存在推斷風險。

已發布的摘要並非可重複利用的漏洞利用方案。它省略了重現堆疊狀態、時序、位址披露與可靠控制所需的目標特定細節。負責任的防禦不需要在正式環境中重現這些階段。存在一條可運作的研究鏈、協調披露、上游修正與穩定回溯，已足以提供修補證據。

幾個界線應保持明確。研究目標使用了 MPTCP。核心建置各不相同。報告的時間僅為一個實驗結果，並非保證的最小值或最大值。網路延遲、CPU 數量、負載、記憶體分配器行為、加固措施與服務實作都可能改變競爭條件。貼文並未表示每個發行版上使用預設設定的普通 TCP 服務同樣可被利用。

因此，最具可辭護性的措辭是：CVE‑2026‑98432 可透過 Linux 網路遠端存取；Anthropic 在受控環境下證明對易受攻擊的 MPTCP 監聽器進行未經認證的 root 程式碼執行；更廣泛的可利用性與可靠性取決於目標。此說法同時保留了緊迫性與準確性。

受影響的版本與廠商回溯

易受攻擊的行為是由較早的上游變更引入的，包括提交 079096f103fa，該提交允許 TCP 與 DCCP 請求 socket 在已建立的 hash 表中安裝時不需要監聽器鎖，還有一個與請求遷移相關的變更。由於受影響的歷史跨越多個維護分支，Linux CVE 記錄列舉了分支特定的修復，而非單一的易受攻擊範圍。

上游穩定修復已在多條維護分支發布。公共記錄中首批已修正的版本包括 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10，以及包含主線修復的 7.3 開發線。這些號碼對上游核心有參考價值，但不應作為供應商套件的通用規則，因為供應商可能將修正回移植至基礎號碼較低的構建，或維護帶有額外修訂識別碼的分支。

以 Debian 的追蹤系統為例，它標示 Bookworm 的 6.1.190-1 安全套件和 Trixie 的 6.12.113-1 套件已修復。它亦記錄了後續套件中的已修正構建。這些套件版本即為 Debian 系統的正確證據。在 Ubuntu 上，安全頁面列出了多個獨立的核心源套件，包括 generic、AWS、Azure、GCP、KVM、Oracle、OEM、low‑latency 和 real‑time 變體。某一變體的狀態並不自動證明另一變體已修復。

Red Hat 使用者應使用 Red Hat CVE 頁面及適用於精確 RHEL 或 OpenShift 產品的勘誤。企業核心故意保留穩定介面與版本族，並同時整合安全修補程式。僅以版本為依據的掃描器若期望上游首個修復版本，可能會將已修正的 Red Hat 核心標記為漏洞。相反地，在裝置中看到高基礎版本並不證明供應商已納入所有穩定修補。

請參考 SUSE CVE 頁面、Gentoo 安全諮詢、雲服務供應商公告與裝置供應商公告，以瞭解各自產品。若供應商尚未公佈判斷，管理員可要求提供 VEX 或支援宣告，確認易受攻擊程式碼是否存在以及哪個構建包含修復。

容器值得特別關注。容器通常共用宿主機核心。更新應用程式映像並不會取代處理其 TCP 流量的核心。受管理的 Kubernetes 客戶可能需要更新節點映像、節點池佈署或供應商維護操作。自主管理叢集則需更新宿主機套件並重啟節點。更換後，請驗證每個節點，而非假設控制平面佈署已覆蓋整個車隊。

Live patching 可能或可能不涵蓋此變更。修復影響網路析構器中的物件回收，覆蓋範圍取決於供應商的 live‑patch 實作與支援決策。僅在供應商明確將其與 CVE‑2026‑98432 相關聯時，才視 live‑patch 狀態為有效。若無此確認…

在變更視窗前建立暴露清單

良好的清單能區分漏洞存在與攻擊可達性。存在性詢問執行中的核心是否包含未修補的受影響程式碼。可達性則詢問哪些不受信任的網路與服務能執行相關握手路徑。兩者皆重要。易受攻擊但隔離的實驗室主機…

先從在 Linux 上直接終止 TCP 的系統開始：反向代理、網頁伺服器、API 閘道、入口節點、VPN 集中器、負載均衡器、郵件閘道、DNS-over-TCP 服務、SSH 堡壘、資料庫端點以及自訂守護程式。若廠商在內部將 Linux 作為底層，亦包含相關裝置。外觀像硬體的邊緣產品仍可能暴露 Linux 網路堆疊。

判斷是否有獨立裝置終止外部連線。雲端負載均衡器可能會吸收公開握手，並與後端建立第二個連線。這可降低網際網路直接存取後端核心的機會，但負載均衡器本身及任何內部不受信任的客戶端仍在範圍內。請將實際連線路徑記錄於資產紀錄，而非僅依賴省略網路終止的應用架構圖。

檢查 MPTCP 狀態。於具備適當 iproute2 版本的系統，可使用 ip mptcp endpoint show 與 ip mptcp limits show 顯示已設定的終端點與限制。若可用，亦檢視 sysctl net.mptcp.enabled。另外辨識那些刻意建立 MPTCP socket 的應用程式；僅有全域啟用旗標並不代表存在監聽器。MPTCP 上游專案檔案 提供測試與部署參考。

使用 sysctl net.ipv4.tcp_migrate_req 檢查 request-migration 設定。預設值與可用性會因核心與設定而異。值為 1 時，先前描述的遷移路徑更具相關性。辨識附加於監聽群組的 reuseport BPF 程式。kernel 的 SK_REUSEPORT BPF 檔案說明程式型別與 socket 選擇情境。缺乏此功能並不證明主要 IPv4 路徑安全，但其存在可協助優先進行測試與推廣。

記錄實際核心、套件、啟動映像、架構與供應商。對於不可變系統，記錄節點映像或作業系統發行版。對於裝置，記錄韌體。對於受管服務，擷取供應商建議或支援案例。此證據比僅顯示「Linux」的試算表儲存格更具價值。

對映信任邊界。僅可從公司 VLAN 存取的服務，仍可能被受損筆記型電腦、工作負載或合作夥伴存取。Kubernetes 節點埠可能以不同於入口設定的方式公開監聽器。即使組織偏好 IPv6，IPv4 暴露仍具相關性，因雙堆疊服務與管理網路常保留 IPv4。

安全驗證，無需利用流量

正式驗證應回答四個問題：正在執行的核心版本、供應商套件、相關服務是否可存取，以及供應商是否表示該精確建置已修復。驗證不應嘗試競賽、破壞核心記憶體、洩露位址，亦不應透過概念驗證執行指令。

以下指令可於您管理的系統收集本機資訊，且不會觸發漏洞：

uname -a
uname -r
cat /etc/os-release

# Debian and Ubuntu package evidence
dpkg-query -W 'linux-image*' 2>/dev/null | sed -n '1,40p'

# RHEL-family package evidence
rpm -q kernel kernel-core 2>/dev/null

# Listening TCP sockets
ss -lntp

# MPTCP state when supported
sysctl net.mptcp.enabled 2>/dev/null
ip mptcp endpoint show 2>/dev/null
ip mptcp limits show 2>/dev/null

# Request migration setting when present
sysctl net.ipv4.tcp_migrate_req 2>/dev/null

以最低必要許可權執行指令。ss 輸出中的程式名稱可能需提升許可權，但監聽位址與埠號仍可在無許可權時使用。若輸出包含主機名稱、內部位址或服務細節，請勿將完整指令輸出貼入公開工單。

接下來，將已安裝的套件與發行版的安全公告進行比對。在 Debian 上，使用 Debian 追蹤器以及已安裝的原始套件版本。在 Ubuntu 上，選擇精確的 kernel 口味與發行列。在 Red Hat 上，使用相應的產品狀態與勘錯。若供應商表示某個 build 已透過 backport 修正，則接受此對映，而非一般上游比較。

確認系統已啟動更新後的 kernel。套件安裝可能成功，但執行中的 kernel 仍舊是舊版。將 uname -r 與重新開機後預期的安裝映像進行比對。在有多重啟動專案的系統上，驗證啟動管理程式選擇了正確的映像。在叢集中，收集每個節點的結果。

對於可從外部存取的服務，使用授權的評估主機透過普通連線嘗試、負載平衡器設定、防火牆政策與服務發現來驗證其可見性。無需傳送格式錯誤的 IP 選項或重複的競爭觸發握手。標準 TCP 連線即可證明不受信任的流量已達到主機。

若實驗室團隊需要更深入的保證，可使用相同供應商映像建立一次性環境，只在該環境啟用 kernel sanitizers，並執行供應商核准的回歸測試。KASAN 文件說明瞭 kernel 的記憶體錯誤偵測器。KASAN 在開發與驗證上非常有價值，但其效能成本與改變的記憶體佈局使其不適合作為正式環境的緩解措施，且可能改變利用程式的時序。

安全驗證報告應包含資產識別碼、業務服務、網路可見性、MPTCP 狀態、如適用則為請求遷移狀態、套件版本、執行中的 kernel、供應商安全公告網址、更新時間戳、重新開機證據、服務健康結果，以及任何臨時例外。該紀錄可支援事件回應、稽核與後續掃描。

偵測與事件回應

記憶體破壞利用很少產生單一明確的紀錄。偵測應結合 kernel 監控、網路行為、主機狀態以及已知的易受攻擊 build。若 kernel 崩潰時堆疊接近 ip_options_build()、ip_build_and_send_pkt()、TCP SYN‑ACK 建構或 socket 破壞，應立即審查。KASAN 報告若識別到涉及 inet_opt 或 ireq_opt 的 use‑after‑free，尤其在測試或除錯環境中相關性高。

檢閱 journalctl -k、dmesg 壓縮檔、崩潰轉儲與平臺序列控制台日誌。雲端例項可能在本地日誌 flush 前就重新開機，因此集中式 kernel 日誌與供應商控制台歷史很重要。若已部署 kdump，請保留 vmcore，並對應未被剝離的 kernel 符號、套件元資料與啟動設定。若證據蒐集是事件計畫的一部份，請勿立即回收受影響節點。

網路監控可識別那些傳送重複連線嘗試且使用異常選項組合，或在 MPTCP 監聽器上持續重試的客戶端。先建立基線。行動網路、易損連結、健康檢查與 SYN 代理可能產生高重傳數。警報應包含目標服務、來源發行版、TCP 選項摘要、速率、持續時間，以及目標在該時刻是否易受攻擊。

Anthropic 所描述的漏洞需要在長時間內重複機會。來自單一來源或協調來源的長期模式因此可能比短暫爆發更值得關注。攻擊者可以分散重試，正常客戶端也可能長時間重試。將此模式視為調查背景，而非簽名。

端點偵測代理對於在核心內部啟動並執行的漏洞具有有限的可見性。一次成功的控制流程劫持可能之後會建立使用者空間程序或更改憑證，但也可能執行與正常特權活動混淆的操作。將意外的 root 程序、啟動設定變更、新網路連線、模組活動、審計事件以及完整性監控警示與核心與網路證據相關聯。

若懷疑被利用，請透過保留證據的網路控制方式隔離主機，依照組織的事件流程擷取易失性狀態，輪換主機可存取的憑證，並調查相鄰系統。核心層級的妥協會破壞對使用者空間日誌與代理完整性的假設。證據蒐集後，應從可信映像重新建置，而非將套件更新視為已被妥協機器的補救措施。

檢查系統是否開放 MPTCP，並確認可疑來源是否能夠連線。保留事件時間附近的防火牆、負載平衡器、流量、封包擷取與服務設定。變更前先記錄啟動的核心與套件。若唯一症狀為崩潰，仍應保留意外觸發或無關錯誤的可能性，同時及時修補。

修補與緩解策略

首選的補救措施是使用包含 RCU 回收修正的供應商核心，接著重新啟動至該核心。使用發行版的常規更新機制及其建議。除非核心供應商或具備經驗的核心工程團隊負責構建，否則避免將單一主線提交挑選至企業核心。穩定分支可能需要相關背景，且未受支援的自訂核心會帶來未來修補與支援風險。

對於整個車隊，按公開可達性、MPTCP 使用、請求遷移、商業重要性、租戶暴露程度及供應商支援等指標對系統排序。先從面向網際網路的節點與終止大量不受信任 TCP 的基礎設施開始。以滾動序列修補冗餘成員：斷開連線、更新、重啟、驗證執行中的核心、執行服務檢查，並在繼續前將節點重新納入輪換。

若無法即時重啟，請降低暴露。若組織未使用 MPTCP，請停用它。將入站 TCP 限制於必要的來源與埠。將管理服務移至已驗證的閘道後方。移除未使用的公開監聽器。在運營安全的上游裝置上套用速率控制或 SYN 代理。這些措施能減少機會並保護特定的公開研究路徑，但無法修正過期指標。

僅與服務負責人一起評估 net.ipv4.tcp_migrate_req 與 reuseport BPF。關閉請求遷移可能減少一條受影響路徑，但亦可能改變故障轉移行為。移除 BPF 程式可能改變流量分佈。配置變更需進行功能測試與回退計畫。

在邊緣阻擋所有 IPv4 選項可能會降低依賴選項資料的路徑曝露，但這是個不完整且可能造成幹擾的控制。部分網路使用選項來實現特殊功能，必須確定過濾器與每條易受攻擊路徑之間的精確關係。中介裝置可能以不同於簡單封包過濾的方式標準化或終止連線。此類控制僅作為臨時風險降低之用。

不要依賴容器重啟、應用程式重新部署或使用者空間函式庫更新。易受攻擊的程式碼執行於主機核心。不要假設網頁應用程式防火牆能看到或理解相關的 IP 與 TCP 握手狀態。於 TCP 連線建立後才開始處理的 WAF 位於易受攻擊操作之下游。

不支援的核心需要直接決策。將工作負載移至支援版本或在替換前隔離。區域性修補的核心適用於專用產品，但需由能驗證回移、測試網路行為、維護符號、發布來源與交付未來修正的擁有者。對大多陣列織而言，切換至供應商支援的核心更安全、更快。

Penligent 透過協助安全團隊整理暴露服務發現、設定證據及在受控補丁視窗內重新測試，支援授權驗證。此核心問題的目標並非在生產環境重現遠端 root 鏈，而是證明哪些資產可存取、收到哪些供應商修正，以及修正後核心啟動後服務是否仍保持健康。

驗證補救措施確實生效

一次成功的更新作業不等於已修復的主機。驗證從重新啟動後開始。使用 uname -r 確認正在執行的核心並將其對應到供應商已修正的套件。確認更新已安裝於預期的啟動分割區，且啟動載入器在發生錯誤後未回復。檢查適用時的安全啟動政策是否已接受該映像。

從信任邊界的兩側驗證服務。內部健康檢查可能通過，但公開監聽器缺失；公開檢查可能通過，私有後端路徑卻損壞。執行正常的 TCP 連線建立、TLS 協商、協議健康與代表性請求。對於 MPTCP 服務，使用組織的常規 MPTCP 功能測試，避免使用惡意時序或記憶體損毀嘗試。

檢視核心日誌中因部署引入的警告。網路修正可能與驅動程式、解除安裝、BPF、負載平衡與自訂模組互動。回歸不應成為無限回到易受攻擊核心的理由。遵循供應商的回退或替換指引，施行臨時曝露降低，並為修正套件升級。

使用能理解供應商回移的掃描工具重新掃描。若掃描器仍標示該資產，附上供應商公告、已安裝套件版本、執行核心證據與修正來源。僅對該版本的精確發現進行抑制，並設定到期或審核日期。基於上游版本比較的廣泛例外可能隱藏後續易受攻擊節點。

對於 Kubernetes 和自動擴充車隊，請驗證範本以及目前的例項。舊的機器映像可能在初次部署後重新建立易受攻擊的節點。更新啟動範本、節點映像、黃金映像、恢復媒體及災難復原定義。測試擴充事件並確認新節點啟動時使用已修正的核心。

對於裝置，請確認韌體升級是否改變了相關的核心建置。保留供應商公告及韌體檢查碼。若裝置供應商尚未發布修正，請記錄補償性控制並取得支援說明。避免假設韌體發布日期晚於上游補丁即自動包含該修正。

僅在以下所有條件均符合時才關閉修復專案：

• 已記錄資產及其實際 TCP 暴露。
• 供應商已確認安裝的建置已修復或不受影響。
• 已修正的核心正在執行，而不僅僅已安裝。
• 已完成必要的重新啟動或供應商批准的 live‑patch 啟用。
• 關鍵服務已通過變更後測試。
• 映像、範本及替換節點來源已更新。
• 臨時緩解措施與例外已指派負責人並設有到期日期。
• 已保留證據以供事件回應與審計。

常見評估錯誤

第一個錯誤是將「Linux」視為單一產品。核心透過發行版、雲端映像、嵌入式韌體、受管節點映像以及自訂建置等方式釋出。每個版本可能包含不同的回溯。請使用準確的產品渠道。

第二個錯誤是將 CVSS 分數與利用率等同。9.8 的基礎分數描述的是度量模型下的技術嚴重度。它不代表易受攻擊的主機數量或證明存在實際利用。5.9 的供應商分數並不排除對其他設定成功的實驗室利用。風險結合了嚴重度、暴露、證據、資產價值及可用控制。

第三個錯誤是把 Anthropic 的結果視為普遍適用。研究證明一支有能力的團隊能在實驗室遠端利用易受攻擊的 MPTCP 監聽器。它並未證實所有 TCP 監聽器的行為相同。請以此為優先考量 MPTCP 與暴露的網路，而非提出未經證實的主張。

第四個錯誤是宣稱 IPv6 一律安全。主要的子 socket 轉移問題是 IPv4 專屬的，而上游說明則另列出涉及 CALIPSO 的 IPv6 遷移關注。雙堆疊系統亦持續暴露 IPv4。請評估兩種協定並遵循後續供應商修正。

第五個錯誤是僅掃描應用程式容器。容器映像在正常模型下不包含主機核心。請盤點並修補節點。Serverless 與受管容器客戶應諮詢供應商，因為即使客戶控制映像，供應商仍控制核心。

第六個錯誤是把公開利用程式碼用作生產測試。故意贏得競賽可能會使機器崩潰或被入侵。當供應商已確認建置易受攻擊後，這也幾乎沒有額外商業價值。安全設定、套件、暴露與補丁後檢查能提供可行證據，且不會將缺陷武器化。

第七個錯誤是在安裝後不重新啟動就關閉工單。除非有供應商支援的 live‑patch 機制覆蓋 CVE，否則舊核心會在系統啟動新映像前持續執行。請始終記錄執行時結果。

常見問題

CVE-2026-98432 是否允許在每臺 Linux 伺服器上進行遠端 root 存取？

• 不。此漏洞可網路存取，且受控研究利用已能在易受攻擊的 MPTCP 監聽器上取得 root 指令執行許可權。
• 可利用性取決於核心編譯、設定、架構、加固、記憶體分配器行為、服務曝光與競態可靠性。
• 所有受影響且可存取的主機仍應修補，因為底層缺陷是核心記憶體破壞。

為什麼 CVE 記錄顯示 9.8，而 Red Hat 卻說 5.9？

• CVE 分數表達的是上游最壞情境的基礎向量：網路存取、無許可權、無互動且高潛在影響。
• Red Hat 針對其產品評分，並考量競態複雜度、預設設定及可能的實際結果。
• 使用供應商評估來確認套件狀態，並參考更廣泛的證據以進行優先排序。

IPv6 受影響嗎？

• tcp_v4_syn_recv_sock() 中的主要問題特定於 IPv4，因為一般的 IPv6 路徑會重複選項。
• 上游說明指出，在使用 CALIPSO 選項時，存在另一個 IPv6 請求遷移問題。
• 請遵循供應商完整的公告，而非簡單標註「IPv6 安全」。

停用 MPTCP 能否修復漏洞？

• 不。它移除公開遠端程式碼執行示範所使用的設定，若不使用 MPTCP 可降低即時風險。
• 底層生命週期錯誤也涉及 IPv4 TCP 請求與子 socket 處理。
• 安裝已修正的供應商核心。

容器需要重新建置嗎？

• 正常的容器模型共用主機核心，因此節點或主機必須安裝核心修補。
• 僅重新建置應用程式映像並不能解決此問題。
• 更新節點範本與管理叢集映像，避免自動擴充重新建立易受攻擊的主機。

如何驗證回溯修補？

• 使用發行版的 CVE 頁面、勘誤、套件變更日誌或 VEX 陳述，針對精確的產品與核心版本。
• 確認已安裝修補套件，並在重新啟動後讓 uname -r 顯示相對應的執行核心。
• 若供應商已檔案化回溯，則不必要求上游首個修復版本。

防禦者應該執行利用概念驗證嗎？

• 生產環境的利用測試不必要，且可能造成主機崩潰或被攻破。
• 驗證核心來源、曝光度、MPTCP 與遷移設定、供應商狀態、重新啟動完成與服務健康。
• 對於任何記憶體安全研究，請使用一次性、授權的實驗室系統。

哪些證據表明已嘗試利用？

• 與 IPv4 選項建構與 socket 銷毀相關的核心崩潰或 sanitizer 發現，是強而有力的技術線索。
• 對易受攻擊的 MPTCP 監聽器重複嘗試不尋常握手會增加懷疑，但並非證明。
• 將網路行為與核心日誌、崩潰轉儲、root 級程序異常以及精確的易受攻擊版本相結合。

最終防禦優先事項

CVE‑2026‑98432 是一個真實的核心物件生命週期失效，具備直接的上游修正與已證明的高影響研究成果。其風險不應被簡化為理論崩潰，也不應被誇大為每臺 Linux 伺服器已可遠端利用。現有證據支援緊急、針對性的行動。

優先處理已公開的 MPTCP 監聽器與面向網際網路的 Linux TCP 終端點。使用廠商套件資料而非一般版本對照。套用修正後的 kernel，重新啟動，驗證服務運作，更新節點與裝置範本，並保留執行修正的證據。若無法立即開啟變更視窗，請停用未使用的 MPTCP、縮減 TCP 暴露，並在排程更新時監控相關 kernel 與握手行為。

最重要的技術教訓不僅限於此 CVE：RCU 保護是讀者與回收者之間的契約。讀者鎖無法保護寫入者直接回傳給分配器的物件。此修補程式透過等待讀者後再釋放共享 IP 選項，恢復了此契約。驗證亦應恢復運營契約：組織應知道哪些主機曾被暴露、執行了哪段修正程式碼，以及修復後服務是否仍正常運作。

MPTCP 與雙堆疊服務的運營備註

MPTCP 的清單往往不如普通 TCP 那般明顯，因為管理員可能知道 kernel 支援此協定，但不知道哪個應用程式綁定了 MPTCP socket。從作業系統層開始，然後詢問服務擁有者他們是否明確建立 MPTCP socket，或是依賴某個庫或代理來協商子流。審查服務單位、容器功能、socket 啟動以及部署設定。主機層級的啟用旗標是一個線索，而非完整的服務地圖。相反地，能使用 MPTCP 的應用程式可能在某個環境下回退到普通 TCP，而在另一環境下則主動以 MPTCP 監聽。

對每個候選服務，記錄監聽器所繫結的位址族與介面。繫結到萬用位址的監聽器可能比其服務設定所示的介面更易被存取。主機防火牆規則、雲端安全群組、網路政策與上游負載平衡器行為皆會影響。有效的紀錄應說明未受信任的客戶端是否能完成通往主機 TCP 堆疊的路徑、代理是否先終止客戶端連線，以及內部客戶端是否在範圍內。這使得能將真正隔離的服務與僅在公共 DNS 區域缺失的服務區分開來。

雙堆疊部署應被評估為兩條相連但獨立的路徑。分別盤點 IPv4 與 IPv6 路由、監聽器、安全群組與轉譯裝置。上游缺陷的主要所有權轉移位於 IPv4 程式碼，但具備 IPv6-only 公共入口的主機仍可透過管理 VLAN、叢集疊加、健康檢查網路或本地對等節點公開 IPv4。IPv6 封包也可能在抵達易受攻擊主機前被翻譯或代理為獨立的 IPv4 連線。網路架構，而非「IPv6-only」等產品標籤，決定了 kernel 會處理哪些資料。

在確認依賴關係前，請勿一次性停用整個車隊的協定。MPTCP 可能是有意設計的移動性或路徑彈性方案的一部分。匆忙的變更可能導致吞吐量下降、失敗切換失效，或改變連線行為，使事件更難診斷。若 MPTCP 未被使用，停用它是可行的臨時降低暴露度措施，但請記錄此變更並驗證服務是否在未察覺的情況下依賴它。若已使用，請優先進行廠商 kernel 推播，並套用與服務目標相容的網路限制。

規劃核心(kernel)變更時，考慮連線狀態

在網路端點進行核心維護時，需考量可用性。重新啟動會中斷已建立的連線，重置某些裝置的連線追蹤狀態，並可能改變路由或解除安裝行為。更新負載平衡服務前，請確認其餘健康節點具備足夠容量。一次排空一個節點，等待長期連線關閉或達到約定的逾時，更新核心、重新啟動，並在重新加入輪替前驗證就緒。若服務使用 MPTCP 於多條路徑，請於變更測試中納入路徑失效處理。

對於有狀態的防火牆與閘道，請確認平臺在滾動維護期間如何處理連線同步。節點可能在程序層面健康，但因路由、隧道狀態或 conntrack 同步尚未收斂，仍不準備接受流量。請加入來自代表性客戶網路的檢查，而非僅限於本機健康端點。依照供應商支援的回滾流程，保留上一版映像，但確保任何回滾都會觸發風險記錄中所述的臨時暴露控制。

將補丁時窗與核心擴充功能及非核心模組同步。儲存、可觀測性、安全與網路代理可能阻止新核心啟動，或在更新後失去功能。請確認所需模組具備相容的編譯與簽章。若重新啟動至舊映像失敗，主機可能仍處於脆弱狀態，而監控僅顯示套件管理器已成功完成。維護後，若期望的已修復編譯與執行時核心不符，請發出警示。

在雲端車隊中，請先更新來源映像再取代例項。若自動擴充群組、例項範本、恢復計畫或管理節點池仍引用舊映像，一次重啟執行中的虛擬機器已不足夠。於相同網路中測試新啟動的替代例項，並確認供應商核心已啟用。對於不可變基礎建設，修復單位往往是映像與發布策略，而非單一主機套件。

在 Kubernetes 中，請將節點驅逐與工作負載中斷預算及持久化儲存限制同步。先更新一個 Canary 節點，驗證 CNI 與服務路由，之後再跨區域進行。DaemonSet 與特權代理應檢查核心版本相容性。容器重新啟動至已修補節點並不代表所有副本已遷移；請蒐集節點層級證據，並將每個工作負載回連至其目前節點。受管理的 Kubernetes 客戶應使用供應商的節點映像與維護指引，因為供應商擁有核心建置。

使用能在後續審核中存續的證據

一份可辯護的修復紀錄能將公告與特定 artefact 連結。儲存供應商的 CVE 頁面或勘誤、套件名稱與修訂版、主機或映像識別碼、更新後的啟動時間與執行時核心字串。若供應商公佈原始碼包狀態，請包含精確的核心變體與發行版。若產品捆綁自訂核心，請附上裝置韌體版本與供應商說明。此舉可避免後續審查者推論通用「Linux 已更新」說明是否涵蓋所有系統。

對於產生 SBOM 的組織，將核心套件連結至受影響資產清單，並在可用時保留 VEX 說明。VEX 記錄可指出產品是否受影響、未受影響、已修復或正在調查，並說明該狀態的依據。當上游 CVE 資料庫顯示廣泛受影響範圍，而發行版已回移植此更改時，這尤其有用。該說明應僅針對確切產品版本範圍；未經證據，請勿將決定套用於不同核心版本。

保留原始與更新後的掃描結果。前後對比可顯示掃描器識別到供應商套件更新，但不應取代供應商對應表。若掃描器在更新後仍報告 CVE，請記錄此發現是舊庫存結果、非支援核心、缺少重啟或因回移植處理產生的偽陽性。未說明的已關閉發現難以辯護，且易被不正確重新開啟。

以負責人、業務理由、補償控制、目標日期及明確再評估條件追蹤例外。對於暫時無法使用的裝置設立例外時，應說明其可接收的網路路徑、所暴露的服務，以及 MPTCP 是否啟用。設定失效時間，而非永久例外。若供應商發布修補程式、新的利用證據出現或裝置的網路邊界變更，請儘早重新評估。

供安全團隊的決策指引

當安全團隊收到 CVE 警報時，首要決策是組織是否擁有相關的核心，而非漏洞掃描器是否已產生發現。查詢端點管理、雲端庫存、虛擬機器映像、Kubernetes 節點池、網路裝置與嵌入式產品紀錄。搜尋核心套件與支援的作業系統族群。來源倉儲或執行時標籤可協助定位系統，但仍需與實際執行的機群做確認。

第二項決策是哪些資產能接收未受信任的 TCP 流量。結合雲端流量紀錄、負載平衡器設定、防火牆政策、服務地圖與主機監聽器。區分直接網際網路流量與由受管代理終止的流量。將可信內部網路納入威脅模型，因受攻擊的工作站與工作負載可能成為未受信任的來源。僅具控制平面功能的裝置仍可能有可從客戶網路存取的資料平面介面。

第三項決策是是否有任何條件提升優先順序。MPTCP 監聽器、請求遷移、reuseport BPF、公開曝光、高價值網路角色或缺乏可靠的主機監控，都應將系統提前進入排程。這些條件並不證明已被利用；它們指出配置更接近已知技術路徑或若被攻破將帶來更高商業衝擊。

第四項決策是如何驗證修補完成。確認支援的修復套件，部署後重新啟動、測試網路服務，並將最終狀態與公告對照。不可以計畫維護單或下載套件作為結案。執行時狀態才是關鍵證據。若無法套用補丁，須記錄時間受限的例外，並在組織取得支援修復前縮減可達路徑。

最後決定是否需要進行事件調查。僅因存在易受攻擊的公開 MPTCP 監聽器就需要緊急修補；但它本身並不證明已被入侵。在存在相關的核心錯誤、可疑的長時間連線嘗試、無法解釋的 root 活動、完整性變更，或針對受影響服務的可信威脅情報時，才加入事件回應。將修補管理與事件回應保持連結但分離，可避免自滿與未經證實的違規宣告。

如何準確傳達風險

高階主管更新應說明受影響資產數量、可存取服務數量、MPTCP 暴露程度、已修補版本可用性、推廣進度以及未解決的例外。不要僅顯示 CVSS 9.8 數值而不說明產品特定的 5.9 評估與研究條件。該數值雖為有用的嚴重性指標，但決策者仍需瞭解自身環境實際執行與暴露的內容。

一個簡潔的技術說明可以這樣寫：‘Linux IPv4 TCP 請求路徑在釋放後仍可使用 IP‑options 記憶體。上游修補透過 RCU 延遲回收。Anthropic 在受控實驗室中證明對易受攻擊的 MPTCP 監聽器進行遠端 root 程式碼執行；但這並未證明普遍可利用。’我們將先修補對外網與啟用 MPTCP 的系統，並在重新啟動後驗證執行中的供應商核心。’此表述傳達了後果、證據、界限與行動，且不會誇大已知資訊。

面向客戶的通訊應遵循組織的事件與漏洞披露政策。僅因系統執行 Linux 就聲稱其易受攻擊是不正確的。請向平臺或供應商查詢準確的核心狀態，並說明是否有已修補版本可用。若需因重新啟動而中斷服務，應將維護影響與漏洞證據分開傳達。

安全團隊亦應保留不確定性。若供應商尚未評估自訂映像，應說明此狀態正在調查中並指出將於何時審查。若未發現 MPTCP 監聽器，請記錄證據與檢查時間。若系統已修補但掃描器未偵測到回溯版本，請附上供應商證明，並將發現保留於可審查狀態，直至資產資料趨於一致。