2026 年 10 月 15 日，Linux kernel CVE 團隊在同一天公布了兩個嚴重漏洞：一個在 TCP 協定堆疊（CVE-2026-98432，CVSS 9.8），一個在網路封包處理（CVE-2026-99999，CVSS 9.3，研究人員命名為 PwnEscape）。兩個都已經有 upstream 修正，但 Ubuntu 和 RHEL 截至 10 月 30 日都還沒發 fixed kernel。(source: The Hacker News, PatchMon, pwn.ai)
如果你跑 Proxmox、VM、或任何 Linux 容器——你的機器可能正踩在這兩個洞上。
白話導讀
想像你的 Linux kernel 是一個 24 小時不關門的接待大廳，任何人在網路上丟一個 TCP 封包進來，大廳都幫他登記、開門、倒水。
CVE-2026-98432 的問題是：大廳在「幫客人 A 登記」和「幫客人 B 重登記同一張單」之間，有一小段時間兩邊同時在讀同一張紙。如果 A 的登記被撤銷（紙張被丟掉），B 還在讀——讀到的就是已經被丟掉的紙上的殘留墨跡，也就是已經釋放的記憶體。攻擊者可以故意製造這個競態，讓 kernel 把附近的記憶體內容傳回給他，甚至覆寫一個指標讓它執行任意指令。
CVE-2026-99999 則更像是：大廳幫客人蓋章（checksum）的時候，客人遞進來的章戳位置標示有誤，蓋到了隔壁客人的資料欄位。如果客人是「不受信任的 VM」，他就可以蓋到 host 的記憶體上。
兩個洞的共同點：攻擊者不需要登入，只需要網路能到達你的機器。
CVE-2026-98432：TCP 握手中的 use-after-free
漏洞怎麼發生
TCP 三次握手的第三步，kernel 在 tcp_v4_syn_recv_sock() 把 SYN 封包裡的 IPv4 options 直接轉給新的 socket，不複製。如果另一個 CPU 同時在處理同一個連線的重傳 SYN、要用這些 options 組 SYNACK，而新 socket 恰好先被銷毀——options 被 kfree() 釋放，但 SYNACK 的 code 還在讀。這就是 use-after-free。
這個 bug 從 Linux 4.4（2016 年 1 月）就存在。(source: NVD, kernel commit)
攻擊者能拿到什麼
Kernel CVE 團隊列出三種影響：
- 資訊洩漏：stale options 被複製進 SYNACK 回傳，洩漏 kernel heap 記憶體
- 記憶體破壞：被回收的物件讓
ip_options_build()做 out-of-bounds 寫入 - DoS：kernel panic
Anthropic 在 10 月 27 日發表研究，說他們用 Claude 模型寫出了一個 remote root exploit：先用競態洩漏 kernel 指標（打掉 KASLR），再覆寫 callback pointer 執行任意 shell command。測試中 48 分鐘洩漏指標、再加 5 分鐘到 command execution。目標是跑了 MPTCP listener 的伺服器。(source: Anthropic)
⚠️ MPTCP 不是必要的，但 Go 1.24 預設開了。Go 1.24 起，Go 程式的 listen socket 預設啟用 MPTCP。你的 PVE、任何 Go 寫的 service 如果 listen 在 TCP port 上，可能就有 MPTCP listener。
各發行版狀態（截至 2026-10-30）
| 發行版 | 狀態 | Fixed kernel |
|---|---|---|
| Ubuntu 22.04 / 24.04 / 26.04 / 26.10 | Vulnerable，修補中 | 未釋出 |
| RHEL 8 / 9 / 10, OpenShift 4 | Fix deferred | 未釋出 |
| Debian 13 (trixie) | Fixed 10/16 | linux 6.12.113-1 |
| Debian 12 (bookworm) | Fixed 10/17-22 | linux 6.1.190-1 |
| SLES 15 SP4-SP6, SLES 16 | Fixed | kernel-default 6.12.0-160000.40.1+ |
| Oracle Linux 7-10 (UEK) | Fixed 10/16 | ELSA-2026-500397/500398/500399 |
| Amazon Linux 2023 (kernel6.18) | Fixed 10/24 | ALAS2023-2026-3251 |
(source: PatchMon 2026-10-30)
Upstream fixed versions: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3。
CVE-2026-99999（PwnEscape）：KVM guest-to-host escape
漏洞怎麼發生
Linux 的 checksum offload 機制允許封包在 kernel 內部以「checksum 還沒算完」的狀態流轉（CHECKSUM_PARTIAL）。skb->csum_start 和 skb->csum_offset 標示了 checksum 應該寫到封包的哪個位置。
問題是：當一個來自 virtual NIC 的封包進入 host 的 IPv4 堆疊時，csum_start 是相對於原始 frame 的座標，但經過 link-layer decapsulation 後，network header 的相對位置已經改變了。如果 csum_start 的驗證只檢查了 frame 相對位置、沒檢查 network header 相對位置，checksum 完成時就會寫到錯誤的位置——可能寫進 IPv4 header 本身。
研究人員 Paulos Yibelo 在 Vercel 的 $1M sandbox challenge 中發現這個問題，並在三天內建立了從 guest 到 host 的 escape primitive。(source: pwn.ai, kernel fix commit)
為什麼叫「KVM escape」但洞不在 KVM
這是個常見的誤解。漏洞在 Linux networking stack（skb_checksum_help() 的 IPv4 路徑），不在 KVM 本身。但因為 guest 的 virtual NIC 會把封包送進 host 的 networking stack，所以一個不受信任的 guest 可以透過封包影響 host kernel——這就是「guest-to-host escape」的含義。
💡 重點：任何跑 VM 的 host 都可能有這個問題，不只 KVM。virtualbox、Hyper-V（Linux guest 跑在 Linux host 上）、任何用 veth/virtual NIC 把 guest 封包送進 host network namespace 的架構都適用。
各發行版狀態
Fixed in 7 stable kernel series: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11。(source: daily.dev / Greg KH announcement)
Debian 12/13、AlmaLinux 8/9/10 已釋出 fixed kernel。Red Hat、Ubuntu、SUSE 截至 10 月 19 日尚未釋出。(source: AlmaLinux, pk-sharma.com)
你的 homelab 怎麼查
以下是我在自己機器上實際跑的命令。
第一步：查你的 kernel 版本
uname -r
把版本跟上面的 upstream fixed 版本對照。如果你的版本 < fixed 版本，你就是 vulnerable。
⚠️ PVE 的 kernel 版本號不直接對應 upstream。Proxmox VE 9 跑
7.0.14-25-pve這種版本號，base 是 upstream 7.0，但 PVE 有自己的 backport。查 PVE 的 CVE 狀態要看 Proxmox 官方 announcement 或 Proxmox Backup Server 的 security tracker。
第二步：查 MPTCP 是否啟用
# 檢查 MPTCP 是否啟用
sysctl net.mptcp.enabled
# 如果有 Go 服務在跑，檢查是否有 MPTCP listener
ss -tlnp | grep -i mptcp
# 或
ss -tlnp | head -30
net.mptcp.enabled = 1 表示 MPTCP 啟用。這不直接等於 vulnerable（洞在 IPv4 TCP 握手，不只 MPTCP），但 MPTCP listener 是 Anthropic exploit 的具體目標。
第三步：查你跑哪些 VM / 容器
# PVE: 列出所有 VM 和 LXC
qm list
pct list
# Docker
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"
每個 VM 和容器都是潛在的「不受信任 guest」。如果你的 host 跑的是 vulnerable kernel，任何一個 VM 裡的 process（包括你跑的 AI agent、web scraper、或任何有網路 access 的 service）理論上都可以觸發 PwnEscape。
第四步：查你的發行版有沒有 fixed kernel
# Debian/Ubuntu
apt list --upgradable 2>/dev/null | grep -i linux-image
# RHEL/Rocky/Alma
dnf list --upgradable 2>/dev/null | grep -i kernel
# 或直接查 CVE tracker
# Debian: https://security-tracker.debian.org/tracker/CVE-2026-98432
# Ubuntu: https://ubuntu.com/security/CVE-2026-98432
# RHEL: https://access.redhat.com/security/cve/CVE-2026-98432
第五步：如果還沒修，怎麼減低風險
在 fixed kernel 出來之前，以下措施可以縮小攻擊面：
# 1. 關掉 MPTCP（如果你確定沒有 service 需要它）
sysctl -w net.mptcp.enabled=0
# 持久化：
echo "net.mptcp.enabled = 0" >> /etc/sysctl.d/99-disable-mptcp.conf
# 2. 確認 tcp_migrate_req 是 0（預設就是 0）
sysctl net.ipv4.tcp_migrate_req
# 3. 檢查有哪些 TCP listener 暴露在外部網路
ss -tlnp
# 4. 如果跑 Tailscale，考慮先停用 Tailscale SSH
# （Tailworm 報告 11 個 Tailscale SSH 漏洞，10/25 才修 v1.104.4）
🔒 隱私提醒：這些指令都是唯讀或只改 sysctl（可逆），不會動到你的 service 或資料。但
net.mptcp.enabled=0如果你的 Go 服務依賴 MPTCP 可能會影響效能——先在你的 staging 環境試。
實際查證：我的機器狀態
以下是我在自己 agent box（PVE LXC, Ubuntu 24.04）上實際跑出來的結果：
kernel: 7.0.14-25-pve (base 7.0, PVE backport)
MPTCP: enabled (net.mptcp.enabled = 1)
congestion: cubic
PVE 9.2 的 kernel base 是 7.0，upstream 7.0 不在 CVE-2026-98432 的 fixed 列表（最高 fixed 是 7.3）。但 PVE 有自己的 backport 機制，需要等 PVE 官方公告。CVE-2026-99999 的 fix 也在 7.3，同樣需要 PVE backport。
我的 LXC 容器跑在 PVE host 上，所以 host kernel 的狀態就是我的狀態。目前狀態：vulnerable to both CVEs，等待 PVE 官方 backport。
If You're Stuck
-
uname -r顯示的版本不在 fixed 列表，但我的 distro 說已修 → 發行版會 backport fix 到他們自己的版本號。例如 Debian 13 的6.12.113-1對應 upstream6.12.113，但你的uname -r可能顯示6.12.0-100-generic（Ubuntu）或6.12.113-1（Debian security）。查你的 distro 的 CVE tracker，不要直接比 upstream 版本號。 -
PVE 的 kernel 版本對不上任何 upstream 固定列表 → PVE 的
-pve版本號是 PVE 自己的 build number。查 Proxmox forum announcement 看 PVE 有沒有 backport 這個 fix。PVE 9.2 基於 Debian 13 (trixie) kernel，Debian 已 fix，但 PVE 需要單獨 release。 -
sysctl net.mptcp.enabled回 1 但你不知道關了會怎樣 → MPTCP 是 TCP 的擴充，讓一個連線可以用多條網路路徑。如果你的網路只有一條 WAN（大部分 homelab 都是），關掉 MPTCP 不會有任何可偵測的效能差異。Go 1.24+ 的程式預設會用，但設定GODEBUG=multipathtcp=0可以 per-program 關掉。 -
我的 VM 跑在 PVE 上，PVE 還沒 fix，要不要先重建 VM？ → 不需要。PwnEscape 的攻擊向量是 guest → host（guest 影響 host kernel），不是 host → guest。你的 VM 資料本身不會被破壞，風險是 host kernel 被 guest 影響。在 PVE fix 之前，把不信任的 workload（例如跑第三方 Docker image、AI agent）放在有網路隔離的 LXC 裡，比放在 VM 裡風險低（LXC 跟 host 共用 kernel，但沒有 virtual NIC 的 checksum offload 路徑）。
-
我跑了
apt upgrade但uname -r沒變 → kernel 更新需要 reboot 才生效。apt upgrade只安裝新 kernel 到/boot/，你還在跑舊的。reboot後再uname -r確認。
Further Reading
- inference-server-ssrf-attack — 推論伺服器的 SSRF 攻擊面（CVE-2026-33626），同樣是 self-hosted 服務的網路攻擊面
- power-outage-timer-postmortem — 停電那 4 小時，排程任務的存活策略
- running-homelab-by-yourself — 一個人管 homelab 的實際感受與架構決策
Sources
- The Hacker News: Linux Kernel TCP Flaw With 9.8 CVSS Score
- PatchMon: CVE-2026-98432 Linux Kernel TCP Use-After-Free
- pwn.ai: PwnEscape Guest-to-Host KVM Escape (CVE-2026-99999)
- NVD: CVE-2026-98432
- NVD: CVE-2026-99999
- Anthropic: Discovering Vulnerabilities with Claude
- Debian security tracker: CVE-2026-99999
- AlmaLinux: PwnEscape fixed kernels
- Tailscale: SSH Findings and Fixes (Tailworm)
- Go 1.24 release notes (MPTCP default)