近期公開的 Linux Kernel 漏洞 CVE-2026-98432（CVSS 9.8 Critical）同時踩中了三個讓維運團隊高度戒備的條件，遠端免認證即可觸發的 Use-After-Free（UAF）、自 Linux 4.4 起潛伏超過十年，而且在漏洞細節與上游修補公開後，Ubuntu LTS 的正式套件更新仍處於排隊整合階段（Pending）。
讓這個漏洞編號在資安圈外也引發廣泛討論的，則是它的挖掘背景，Anthropic 研究員 Xinyang Ge 通報上游後，Frontier Red Team 揭露其未公開模型 Claude Mythos 在沒有人類提示方向的情況下，讀完修補概念後花不到 50 分鐘，就針對 Multipath TCP（MPTCP）listener 自主串出一條兩階段遠端 Root RCE 攻擊鏈（第一階段利用 UAF 造成資訊洩漏繞過 KASLR，第二階段透過記憶體重分配劫持控制流）。
當各家資安通報都在討論 AI 自主寫出 Kernel 0-day Exploit 時，手上有 Ubuntu 22.04 或 24.04 節點或 RHEL 的工程師更關心幾個實務問題：
- 在 Canonical 的
apt upgrade還沒下來之前，手上的 Ubuntu 主機預設曝險到什麼程度？ - 官方與社群建議的
nftables攔截IHL > 5（IPv4 Options）與關閉 MPTCP，實測能否 100% 擋住觸發路徑？會不會拖慢正常 TCP 交握？
CyberQ 分析 CVE-2026-98432 的底層成因與各發行版修補現況，再以一台執行 Ubuntu 24.04.5 LTS（Kernel 7.0.0-1024-nvidia）的實驗機，利用隔離網路命名空間（Network Namespace）完整跑一輪封包構造、Raw Socket 擷取、nftables 攔截驗證與 500 次交握延遲基準測試。以下全數輸出與截圖皆已完成去機敏化處理。
漏洞機制，為什麼一個 kfree() 會在十年後變成遠端 RCE？
問題出在 Linux Kernel IPv4 TCP 交握路徑對 IPv4 Options（struct ip_options_rcu）的所有權轉移與釋放方式。
早在 2015 年的 Linux 4.4（Commit 09f2b1f2b820），為了提升高平行處理 SYN 處理吞吐，Kernel 讓 TCP Request Socket 在處理時不再全程持有 Listener Lock。然而在 net/ipv4/tcp_ipv4.c 的 tcp_v4_syn_recv_sock() 中，當三向交握完成、準備由 Request Socket（ireq）建立正式 Child Socket（newinet）時，核心直接把指標交接過去：
/* net/ipv4/tcp_ipv4.c : tcp_v4_syn_recv_sock() */
newinet->inet_opt = ireq->ireq_opt;
如果此時遠端攻擊者刻意高速發送帶有 IPv4 Options（Header 長度 IHL > 5，即大於 20 bytes）的 TCP SYN 與重傳封包，在多核心併發（特別是透過 MPTCP listener 觸發的子流程）下，就會出現以下四步競爭視窗：
- 配置選項記憶體：攻擊者送入帶有 IPv4 Options（
ver_ihl為0x46至0x4f）的 TCP SYN 封包，核心在 Request Socket 上配置ireq->ireq_opt。 - 無鎖指標轉移：併發 ACK 與重傳 SYN 到達時，
tcp_v4_syn_recv_sock()將ireq->ireq_opt指派給newinet->inet_opt。 - 未等待 RCU 即釋放：當其中一條路徑因異常或重傳觸發
inet_sock_destruct()或tcp_v4_reqsk_destructor()時，核心直接呼叫一般的kfree()將記憶體釋放回 Slab，而沒有等待 RCU Grace Period 結束。 - 跨核心 Use-After-Free：同一時間另一個 CPU 核心仍在
rcu_read_lock()保護下讀取該份ip_options_rcu構造回應封包。攻擊者只要透過 Heap Spray 佔用剛釋放的 Slab 槽位，就能達成資訊洩漏（繞過 KASLR）與控制流劫持。
Eric Dumazet 提交的上游修補（Commit e3f33b0a1d89d738e2b913dab519226eaf76e15b，標題 “ipv4: free inet_opt and ireq_opt after an RCU grace period”）只改了兩個檔案，把兩個 destructor 裡的 kfree() 換成 kfree_rcu()：
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -162,7 +162,7 @@ void inet_sock_destruct(struct sock *sk)
- kfree(rcu_dereference_protected(inet->inet_opt, 1));
+ kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2380,7 +2380,7 @@ static void tcp_v4_reqsk_destructor(struct request_sock *req)
- kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
+ kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu);
看懂這段修補，防禦邏輯就非常清楚了，只要進入主機的 TCP 封包沒有攜帶 IPv4 Options（IHL == 5），ireq_opt 與 inet_opt 永遠是 NULL，整條 UAF 程式碼路徑根本不會配置記憶體，也就不可能被觸發。
Ubuntu 官方修補現況（截至 2026 年 11 月 1 日）
檢視 Ubuntu Security Tracker 的 CVE-2026-98432 頁面，目前各 LTS 版本的 linux 套件狀態如下：
| Ubuntu 發行版 | 套件狀態 | 說明 |
|---|---|---|
| Ubuntu 26.04 LTS (Resolute) | Pending | 正在整合上游 Patch，尚未釋出 apt 更新 |
| Ubuntu 24.04 LTS (Noble) | Pending | 主線與衍生分支（含 linux-nvidia）尚在打包測試中 |
| Ubuntu 22.04 LTS (Jammy) | Pending | 尚未釋出正式安全更新 |
| Ubuntu 20.04 LTS (Focal) | Vulnerable (EoSS) | 標準支援已結束，需透過 Ubuntu Pro ESM 取得後續修補 |
換句話說，依賴標準 apt update && apt upgrade 的 Ubuntu 22.04 與 24.04 主機目前正處於修補空窗期。
實測一：Ubuntu 24.04 LTS 的預設曝險盤點
為了不在正式網路介面製造干擾，CyberQ 在 Ubuntu 24.04.5 LTS（Kernel 7.0.0-1024-nvidia）上使用 bwrap 建立具備 CAP_NET_ADMIN 與 CAP_NET_RAW 的隔離 Network Namespace，首先盤點系統預設狀態。
盤點結果揭示了一個容易被忽略的事實，在 Ubuntu 24.04 LTS 上，即使管理員從未主動設定 Multipath TCP，系統預設參數就是開啟的：
net.mptcp.enabled = 1（預設啟用）- 套件狀態：
linux-image-7.0.0-1024-nvidia（版本7.0.0-1024.25~24.04.1），編譯時間為 2026 年 10 月 22 日，早於上游修補與 CVE 公告。 - Socket 驗證：任何程式只要呼叫
socket(AF_INET, SOCK_STREAM, 262)（IPPROTO_MPTCP），核心就會立刻啟用 MPTCP 狀態機。
在實測過程中我們還發現一個有趣的底層細節：如果在 Client 端 建立 IPPROTO_MPTCP socket 並嘗試呼叫 setsockopt(SOL_IP, IP_OPTIONS, ...)，Linux 核心的 mptcp_setsockopt() 會直接回傳 Errno 92 (ENOPROTOOPT) 拒絕設定；但遠端攻擊者根本不需要在 Client 用 IPPROTO_MPTCP。只要 Server 端 是 MPTCP 或一般 TCP Listener，攻擊者直接用標準 IPPROTO_TCP socket 或 Raw Socket 掛載 IP_OPTIONS 發送 SYN 封包，Server 端的 tcp_v4_syn_recv_sock() 就會照單全收並配置 ireq_opt。
實測二：Raw Socket 封包擷取與 IHL > 5 觸發路徑驗證
為了確認未設防狀態下核心如何處理帶有 IPv4 Options 的交握封包，CyberQ 在隔離命名空間的 127.0.0.1:18443 啟動 IPPROTO_MPTCP Listener，並掛載 AF_PACKET Raw Sniffer 擷取四種不同 IPv4 Header 長度（IHL）的 TCP SYN 封包：
四組測試向量的實際擷取結果整理如下：
| 測試向量 | ver_ihl 位元組 | IHL (32-bit words) | IPv4 Header 長度 | 攜帶之 IPv4 Options Hex | 未防護交握結果 | ireq_opt 記憶體配置 |
|---|---|---|---|---|---|---|
| 標準 TCP SYN | 0x45 | 5 | 20 Bytes | (none) | CONNECTED | 不配置 (NULL) |
| 4B NOP Padding | 0x46 | 6 | 24 Bytes | 01010101 | CONNECTED | 配置並轉移至 inet_opt |
| 8B IP Timestamp | 0x47 | 7 | 28 Bytes | 44080900012a5054 | CONNECTED | 配置並轉移至 inet_opt |
| 12B Record Route | 0x48 | 8 | 32 Bytes | 070b087f0000010000000001 | CONNECTED | 配置並轉移至 inet_opt |
從擷取到的原始 IPv4 Header 可以清楚看到第一個 Byte 的變化，標準 IPv4 封包恆為 0x45（Version 4，IHL 5 = 20 bytes），一旦掛上 4 bytes、8 bytes、12 bytes 的 IP Options，第一個 Byte 立刻變成 0x46、0x47、0x48。在預設無防火牆規則的情況下，這三種攜帶 IP Options 的連線全部順利完成三向交握，直接走進 ireq_opt -> inet_opt 的問題路徑。
實測三：nftables 精準攔截與 MPTCP 雙重加固
現代網際網路上的正常業務流量（HTTP/HTTPS、SSH、gRPC、資料庫連線）幾乎 100% 不使用 IPv4 Options（IHL 恆等於 5）。因此，在 Netfilter 的 raw 優先級（-310，早於 Connection Tracking conntrack 的 -200）直接丟棄 ip hdrlength > 5 的 TCP 封包，是成本最低、隔離最徹底的做法。
我們在實驗環境中套用以下 nftables 規則：
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop comment "CVE-2026-98432: drop IPv4 TCP packets with IP options (IHL > 5)"
}
}
接著發起混合流量驗證：
- 100 次正常 TCP 交握（
IHL = 5，20B Header）：100 / 100 全數連線成功（100% 通過，0 誤殺）。 - 30 次攜帶 IPv4 Options 的異常 TCP SYN（
IHL = 6NOP × 10、IHL = 7Timestamp × 10、IHL = 8Record Route × 10）：30 / 30 全數在priority -310被丟棄（100% 攔截），完全無法進入 TCP Listener 或觸發ireq_opt配置。
查詢 nft list table inet cve_2026_98432 的核心計數器，精準記錄了這 30 個被攔截的異常封包（共 2,040 bytes）：
ip protocol tcp ip hdrlength > 5 counter packets 30 bytes 2040 drop
同時，執行 sysctl -w net.mptcp.enabled=0 後，再次嘗試建立 IPPROTO_MPTCP (262) Socket 立即被核心以 ENOPROTOOPT (Protocol not available) 拒絕，徹底切斷兩階段 RCE 攻擊鏈所依賴的 MPTCP 攻擊面。
實測四：這條防火牆規則會拖慢正常連線嗎？
高併發服務的維護者通常會關心：在每個進入的 TCP 封包上多加一條 nftables 表頭長度檢查，會不會增加交握延遲？
我們針對正常 TCP 連線（IHL = 5）先暖機 50 次，再分別於「未掛載規則」與「掛載 cve_2026_98432 攔截規則」下各跑 500 次連續 TCP 交握，量測端到端延遲（單位為微秒 µs）：
| 統計指標 | 未掛載規則 (Baseline) | 掛載 nftables 規則後 | 差異 (Delta) |
|---|---|---|---|
| 樣本數 (Iterations) | 500 | 500 | 無 |
| 最小值 (Min) | 4.67 µs | 4.67 µs | +0.00 µs |
| 中位數 (Median / p50) | 8.71 µs | 7.95 µs | -0.76 µs（落於量測抖動範圍內） |
| 平均值 (Mean) | 9.85 µs | 9.19 µs | -0.66 µs |
| p95 延遲 | 13.19 µs | 12.15 µs | -1.04 µs |
| p99 延遲 | 16.31 µs | 49.62 µs | +33.31 µs |
中位數與 p95 延遲在掛載前後都維持在 8 至 13 µs 水準，差異小於 1 µs（完全落在作業系統排程的正常抖動範圍內）。原因是 ip hdrlength > 5 只對 IPv4 Header 第 0 個 Byte 的低 4 位元（Nibble）做一次常數時間位元遮罩比對，且掛在 priority -310（NF_IP_PRI_RAW - 10），連狀態追蹤（conntrack）都不必查。
給 Ubuntu Linux 維運人員的無停機緩解清單
在 Canonical 釋出正式的 linux-image 安全更新（或 Canonical Livepatch）之前，若您的 Ubuntu 22.04 或 24.04 主機有對外開放 TCP 服務，建議依環境需求評估執行以下兩步加固（不需重開機、不中斷現有連線，若主機僅位於受控內網且無對外曝露，則可等待官方套件釋出後直接更新）：
1. 部署 nftables 攔截 IHL > 5 之 TCP 封包
sudo nft -f - << 'EOF'
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop comment "CVE-2026-98432 mitigation"
}
}
EOF
若環境仍使用舊版 iptables，可透過 u32 模組比對 IHL 欄位大於 5（即表頭大於 20 bytes）：
sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>22&0x3C>20" -j DROP
2. 關閉未使用的 Multipath TCP（MPTCP）與 Source Routing
sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
# 寫入持久化設定，重開機後仍生效
cat << 'EOF' | sudo tee /etc/sysctl.d/99-cve-2026-98432-mitigation.conf
net.mptcp.enabled = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
EOF
3. 日後更新釋出後的清理方式
當 apt list --upgradable 出現包含 CVE-2026-98432 修補的新版 Kernel 並完成重開機後，只需一行指令即可移除臨時防火牆表：
sudo nft delete table inet cve_2026_98432
簡單的修補後，等官方更新
CVE-2026-98432 是一個典型的「修補極小（兩行 kfree_rcu）、影響極廣（十年以上 Kernel）、武器化速度卻因 AI 而大幅縮短」的現代漏洞樣本。面對發行版打包測試與釋出的時間差，第一線面對公網的節點不必被動等待套件更新，直接在網路入口把現代業務流量幾乎不再使用的 IPv4 Options (IHL > 5) 擋在 raw 表之外即可。本次實測證明，這條規則既不會傷及任何正常連線，也不會帶來可感知的效能代價。
