2026 年 11 月 3 日，距離 kernel.org CNA 公開 CVE-2026-98432 已滿 19 日。Ubuntu 22.04、24.04 與 26.04 三個 LTS 的 archive 內核，仍全部停在修復版本之前：22.04 是 5.15.0-202.212、24.04 是 6.8.0-147.147、26.04 是 7.0.0-42.42；Canonical 指出帶修復的分別為 5.15.0-203.213、6.8.0-149.149 與 7.0.0-43.43。三個修復版本目前只存在於 -proposed，因此在標準 24.04 機器上執行 apt upgrade，今日解析到的仍是 6.8.0-147.147。同期 Debian 於 10 月 16 日以 DSA-6568-1 為 trixie 出貨 6.12.113-1，距公開僅一日。
先修正三個常見說法
一、修復不是不存在，而是尚未完成認證。Canonical 已於 10 月 26 日與 28 日把三個 LTS 的修復內核上傳至 -proposed，並在 11 月 2 日的說明文章中列明各版本號。26.10（stonking）更已於 11 月 2 日把 7.3.0-10.10 發布至 -security，屬真正出貨。把現況寫成「Ubuntu 完全沒有動作」，與 archive 記錄不符。
二、沒有公開 exploit。Anthropic 在 10 月 27 日的文章中描述其模型針對設有多重路徑 TCP listener 的伺服器寫出可用 exploit，但未發布任何程式碼；Canonical 稱其為「尚未發布的 exploit」，CISA KEV（2026.10.30 版，1,766 條）亦未收錄此 CVE。已演示的 remote root 是單一實驗室設定，不是此漏洞的通例。
三、9.8 分屬於 CNA，不是 NVD，也不是 Ubuntu 的評估。9.8 出自 kernel.org CNA 的 CVSS 3.1 向量；NVD 記錄狀態為 Received，未提供主要評分。Ubuntu 自己的 CVSS 4.0 評估為 8.3（High），追蹤頁的優先級亦為 High。另一個容易誤寫的數字是 USN：通知 API 對此 CVE 的回傳筆數為 0，至今沒有任何 USN 引用它，最新一則 USN 仍是 10 月 29 日的 USN-8958-1。至於 14.04，其內核早於 4.4 引入缺陷的提交，狀態為不受影響，不在需處理之列。
逐版本對照：archive 與修復版本的距離
| 版本 | 代號 | archive 現行內核 | 帶修復版本 | 修復所在 | apt upgrade 是否修好 |
|---|---|---|---|---|---|
| 26.10 | stonking | 7.3.0-10.10 | 7.3.0-10.10 | security / updates | 是 |
| 26.04 LTS | resolute | 7.0.0-42.42 | 7.0.0-43.43 | -proposed | 否 |
| 24.04 LTS | noble | 6.8.0-147.147 | 6.8.0-149.149 | -proposed | 否 |
| 22.04 LTS | jammy | 5.15.0-202.212 | 5.15.0-203.213 | -proposed | 否 |
| 20.04 LTS | focal | — | 未排定 | 狀態 needed | 否（ESM） |
| 18.04 LTS | bionic | — | 未排定 | 狀態 needed | 否（ESM） |
| 16.04 LTS | xenial | — | 未排定 | 狀態 needed | 否（ESM） |
| 14.04 LTS | trusty | — | — | 不受影響 | 不適用 |
表內兩點需一併讀。22.04 的 202.212 雖在 10 月 29 日才發布至 -security，日期看似最新，但 ABI 比修復版低一級，不可能含有修復；這是三個 LTS 中最容易被誤判為「已更新」的一列。26.10 的追蹤頁仍顯示 work in progress，原因是頁面最後更新時間為 10 月 30 日，早於 11 月 2 日的 -security 發布，屬追蹤延遲而非修復缺失。
-proposed 究竟代表什麼
-proposed 是 Ubuntu 的預發布 pocket，預設不參與升級，套件需先通過 Canonical 約 2,000 部機器的認證測試，才會被複製到 -updates 與 -security。Canonical 在說明文章中明言，測試完成後才會把這些內核移入 -updates，並未公布時間表。因此「修復已在 -proposed」的正確意思是：修復已寫好、已上傳、可被取用，但尚未取得發行資格；它既不是「已修復」，也不是「沒有修復」。這個中間狀態，正是三個 LTS 用戶當前面對的全部差距。要確認機器是否已達修復版本，apt-cache policy linux-image-generic 的 Candidate 比追蹤頁可靠，因為追蹤頁可能落後於 archive。
Debian 的時間線：一日與十九日
上游把修復併入七個穩定分支：6.12.113 與 5.15.223 均於 10 月 15 日標記（前者為當日 11:56，UTC+2），7.2.10 更早於 10 月 11 日已含修復。Debian 在公開後一日內完成 trixie 的 6.12.113-1，於 10 月 16 日 13:39 發出 DSA-6568-1；bookworm 的 6.1.190-1 於 10 月 17 日以 DLA-4841-1 補上，可選的 6.12 系列則在 10 月 22 日以 DLA-4850-1 出貨。forky 與 sid 分別為 7.2.12-1 與 7.2.15-1，早已越過修復點。差距不在技術難度，而在發行流程：Debian 把同一批上游修復直接併入穩定版內核，Ubuntu 需先經過認證佇列。DSA-6568-1 一次上傳列出約 200 個 CVE，CVE-2026-98432 只是其中之一，說明 Debian 的做法是把上游穩定分支的累積修復整批併入，而非為單一 CVE 另開流程；Ubuntu 的 -proposed 同樣是批次處理，但每個內核需逐版認證，這正是三個 LTS 同時卡住的結構原因。
可行緩解清單（按可驗證程度排序）
- 啟用 -proposed 並安裝待驗內核（Canonical 建議路徑，涵蓋 22.04、24.04、26.04）。執行
sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu，更新後以-t <代號>-proposed升級 linux-meta 套件並重啟。代價明確：這些套件未完成認證，屬預發布曝露。 - 改用 kernel.ubuntu.com 的 mainline 內核。6.12.113 的 mainline 組建存在（頁面回傳 200），7.2.10 則沒有（404），因此實務上會落在 6.12 或之後的 6.17 組建。此路徑失去 Canonical 支援，不帶 Ubuntu 的 SAUCE 補丁，亦可能破壞 DKMS、ZFS 與 NVIDIA 驅動。
- 在網絡層丟棄帶 IPv4 options 的入站 TCP，並關閉 MPTCP。AlmaLinux 與 AWS 公告提供 nftables 規則與 Suricata 特徵（
ipv4.hdr; bsize:>20）。僅屬部分有效：只擋跨主機 SYN，同主機容器之間的流量可繞過，且 MPTCP 只是 exploit 選用的路徑，不是漏洞前提。Ubuntu 安全團隊明言不背書此類規則。 - 以
init_on_free=1開機。這是加固而非修復：釋放後的記憶體被清零，洩漏的物件讀回零值，但 stale pointer 仍會被解引用。代價約為 free 密集工作負載的 1% 至 5%。 - Canonical Livepatch：目前不可依賴。CVE 頁面與說明文章均無 Livepatch 條目，且 livepatch 需由源碼修復生成；修復仍只在 -proposed 時，沒有可訂閱的串流。應視為未驗證，而非緩解措施。
- ESM 版本（20.04、18.04、16.04）：追蹤狀態為 needed，未排定版本，亦無時間表。使用者應向 Canonical 支援確認，不應假設會自動獲得修復。
常見問題
修復已在 -proposed，是否等於已修好？
不等於。預設的 apt upgrade 不會取用 -proposed，內核需通過認證後才移入 -updates 與 -security。除非主動啟用該 pocket，否則機器仍跑在帶漏洞的版本上。
26.10 的追蹤頁仍寫 work in progress，是否未修？
已修。7.3.0-10.10 於 11 月 2 日進入 -security，與 Canonical 文章所列版本一致；追蹤頁的 10 月 30 日更新時間早於發布，屬延遲。
9.8 分是否代表所有 Linux 伺服器可被 remote root？
不代表。9.8 是 CNA 按最壞情況給的 CVSS 3.1 分數，Ubuntu 自評為 8.3；已演示的 remote root 只在 Anthropic 未公開的 PoC，且要求目標設有 MPTCP listener。
更新內核後需要重啟嗎？
需要。內核只在下一次開機載入，安裝完成不代表執行中的內核已修；重啟後以 uname -r 核對版本號是否達到上表所列的修復版本。
把三個修正放回原位之後，這宗 CVE 的形狀就清楚了：上游在 10 月 15 日已給出修復，Debian 用一日完成出貨，Ubuntu 用十九日走到「已上傳、待認證」。差距不在能力，而在一個尚未公布時間表的認證佇列。你手上那台 Ubuntu，uname -r 顯示的是哪一個版本？
分類：Technology
標籤：Linux 核心 · CVE-2026-98432 · Ubuntu · 資訊安全 · 修補管理 · Debian
