2026 年 7 月 28 日 embargo 到期，安全研究者 Asim Manizada 把 CVE-2026-64531 寫進 oss-security 公開名單，同一天釋出一份帶有約 800 份預建 offset 的 PoC。這支洞代號 OVSwrap，藏在 Linux kernel 的 Open vSwitch 資料路徑裡整整 13 年——2013 年當初的實作就把生成後的 action stream 存進 nla_len 只有 16 位元的 Netlink 屬性裡，只是那時上層有 32 KiB 的總長度硬上限擋著，回捲永遠不會發生。2025 年 3 月主線為了支援更複雜的 conntrack 場景把這個硬上限拿掉，個別 nested attribute 的長度檢查卻沒補上，這個潛伏 bug 才真正被引爆。
真正讓這支 CVE 值得每一台 VPS 主機商認真看的是它的攻擊面：不需要 Open vSwitch 有任何設定、不需要現成的 OVS bridge、不需要 ovs-vswitchd daemon 在跑、也不需要在初始 namespace 裡有 CAP_NET_ADMIN。只要 openvswitch 模組能被 modprobe 拉起來，本機任一個一般帳號透過 unshare -Urn 開個 user namespace，就能把整條鏈跑到寫入 /etc/sudoers.d/ 拿 root。多數 VPS 主機根本沒用 OVS，但 openvswitch.ko 幾乎都靜靜躺在 /lib/modules 底下等著被自動載入。
16 位元的 nla_len 是怎麼被撐爆的
Open vSwitch 從 userspace 收到一份 action list 後，會在 kernel 端做 validate 加 rewrite——把某些高階 action（例如 CLONE 包一整組 conntrack）展開成更完整的 sw_flow_actions 內部串流。這個內部串流的每個節點都是 Netlink 屬性，nla_len 欄位只有 16 位元寬（65535 bytes 上限）。
2013 年這條路徑寫出來的時候，另一層還有 OVS_MAX_ACTIONS_LEN 這個 32 KiB 硬上限守著，任何生成後的串流都不可能突破 65535，nla_len 回捲物理上根本不會出現。這個「上限保護底下的長度欄位」組合就這樣安穩活了 12 年。
2025 年 3 月主線的一個 commit 把 32 KiB 上限移除，允許 action stream 超過 64 KiB，卻沒同步在展開路徑上檢查單個 nested attribute 是否超出 16 位元容量。攻擊者只要送一個 CLONE，裡面塞入好幾百個 conntrack action，kernel 在展開時累積過 65535 bytes，某個節點的 nla_len 就被截斷成一個小數字。之後的 dump 或 free 消費者信任這個回捲後的長度、從 attacker-controlled 的 conntrack label 與 timeout name 那段開始重新 parse，虛構的 OUTPUT 跟 SET action 就這樣被 kernel 當成合法動作處理下去。
修補進了 upstream commit 3f1f75536668，主旨一句話：net: openvswitch: reject oversized nested action attrs——展開時若偵測到單個 nested attribute 超過 65535 就直接拒絕。這個 bug 的形狀是典型的「潛伏型不變量假設」，2013 到 2025 之間的每一份 code review 大概都會看到「這裡 caller 已經保證不會超」的隱含假設，直到有人動了 caller 那條邊界。
一個 unshare 就從 user namespace 提到 host root
會讓這支 CVE 特別致命的是它對執行環境要求極低。攻擊者不需要在 host 上有 CAP_NET_ADMIN、不需要事先做任何 OVS 設定，只要 unshare -Urn 開一個 user namespace 加 network namespace，在這個 namespace 裡就自動擁有 namespace 內的 CAP_NET_ADMIN，可以呼叫需要 OVS_GENL 操作的 syscall。這一 syscall 觸發 kernel 端 auto-load openvswitch 模組，接下來所有攻擊都發生在 host kernel 記憶體上——user namespace 這一層根本擋不到 kernel 自己被踩爛。
公開 PoC 的完整鏈長這樣：長度回捲取得 kernel pointer leak → 沿著這個 pointer 做定向 kernel memory read → 精準減量 primitive 定位到 host 某個 root process 的 cred struct → 把該 process 的 uid/gid 直接改為 0 → 讓該 process 寫一份 /etc/sudoers.d/pwn 讓一般帳號無密碼 sudo → 攻擊者從自家帳號直接 sudo -s。
整條鏈公開的 PoC 帶著約 800 份 kernel offset 表，涵蓋主流 distro 的常見組合。這意味著門檻已經降到「找到 uname -r 對得上就一鍵拿 root」，任何允許使用者跑任意 binary 的環境——CI runner、共享 shell、教學帳號、學術叢集、多租戶 PaaS——都是首波掃描目標。
影響版本與現場實際暴露面
第一次修復進 stable 是 5.15.212、6.1.178、6.6.145、6.12.97、6.18.40、7.1.5。反推可被打的區間主要落在 5.15.180–211、6.1.132–177、6.6.84–144、6.18.0–39、7.1.0–4，這幾段對應到 Debian 12/13、Ubuntu 22.04/24.04 LTS、RHEL 9.7+/10.1+ 與 Amazon Linux 2023 相當常見的組合。臺灣多數用 Ubuntu 24.04 或 Debian 12 開起來的 VPS 幾乎都落在受影響區間。
決定「這台機器是否會被打」的關鍵不是 OVS 有沒有被設定，而是三件事：openvswitch 模組是否還能被 modprobe 拉起來、unprivileged user namespace 是否還開著（絕大多數發行版預設是開的）、以及 kernel 是否已經打到修復版本。7 月 28 日到 8 月初這段時間如果沒有立即打 patch，機器就處於 PoC 現成、offset 現成、隨時可以被批次掃描的狀態。
沒辦法馬上打 patch 的兩層獨立緩解
擋模組加載跟關 user namespace 這兩層各自都可以擋下這支 CVE，理想是兩層都上。
擋模組載入的正確寫法不是只放一句 blacklist，因為 blacklist 只影響 udev 觸發的自動載入，對 kernel 自身 on-demand 載入無效。要跟 install 指令合在一起才會生效：
1 | # /etc/modprobe.d/99-ovswrap.conf |
寫完之後把已經被載入的模組 modprobe -r openvswitch 拔掉。若拔不掉表示有其他模組依賴它（例如 OpenStack Neutron agent），這種情況只能走 kernel patch 這條路。
關 user namespace 則是這樣：
1 | # /etc/sysctl.d/99-ovswrap.conf |
這一步會擋掉 rootless Docker、rootless Podman、Chrome/Firefox 的 sandbox、還有部分 CI runner。「沒在跑 rootless container 的伺服器」把這一項關掉是安全收益最大的做法；有跑 rootless container 的機器則優先走 kernel patch 或走分租戶隔離。
AppArmor 的 kernel.apparmor_restrict_unprivileged_userns 不夠用——已經有公開繞過方式，不要拿它當唯一防線。
現在該掃的痕跡跟該加的監控
打完 patch 或緩解上完，還要驗兩件事：模組確定載不進來（modprobe openvswitch 應該直接吐錯）、既有機器上有沒有已經被打過的痕跡。PoC 落地後最容易留下的證據是 /etc/sudoers 或 /etc/sudoers.d/ 下多了非預期的檔案、非 setuid 出身的程序卻跑成 root credential、以及非預期時間點的 user/network namespace 建立紀錄。
主機商規模夠大的話，比較實務的做法是把 /etc/sudoers.d/ 目錄做 auditd 的 -w 追加監控、把「非白名單程序卻具備 setuid ancestry」的檢查寫進日常 baseline。這一輪之後可以預期會有更多攻擊者把 unshare -Urn 加 kernel LPE 當作 lateral movement 的標準組合，共用主機類型的服務都要提早準備這條偵測路徑。
live patching 值不值得為了這一支 CVE 訂閱
擋模組跟關 namespace 都是靜態緩解，真正解問題還是要打 kernel patch。走 apt/dnf 常規升級加 reboot 是最乾淨的路，但 VPS 主機商每台 reboot 就是一次客戶維護窗口通知。這類場景 live patching 產品（KernelCare、Ubuntu Livepatch、Oracle Ksplice）的價值會被明顯放大：在跑的 kernel 上直接補這條 validation 路徑，不用 reboot 也不用把 VM 重新 attach。
值不值得訂閱要看規模。手上一兩台機器直接 reboot 就結束；管十台以上、且每次 CVE 都要開維護窗口通知的團隊，把 live patching 訂閱費算進安全預算通常會划算，尤其 2026 年這幾波 kernel 級別 LPE（Copy Fail、GhostLock、Zapscape、OVSwrap）已經證明修補節奏會越來越急，客戶對「主機商多久打完 patch」的敏感度也在上升。
給臺灣自架 VPS 現場的一段判斷
Linux 6.19 剛帶進主線的 LUO（Live Update Orchestrator）未來會逐步把「kernel patch 完再 reboot」的成本壓成 5 到 15 秒的 kexec handover，但目前要等 QEMU、libvirt、cloud-hypervisor 這條 userspace stack 支援完成還要幾個版本。當下（2026 年 8 月）現實的組合是：不用 OVS 的機器直接雙保險（擋模組加關 namespace）、有用 OVS 的機器優先 kernel patch 加 live patching、有跑 rootless container 的機器只有 kernel patch 一條路。
這一輪 CVE 的教訓不新——「上層有 caller 保證，所以下層長度欄位不用檢查」這種假設，只要有人動了上層邊界就會全數崩盤。任何時候在 code review 看到「這裡 XX 已經在上層擋掉了」這類註解，都該把它當成下一支 CVE 的候選位置對待。
在臺灣本地跑 KVM 平台、需要一台網路架構穩定、可以搭配即時打 patch 節奏的 VPS 主機，NCSE Network 的方案位於是方電訊南港機房，全機 Intel Gold CPU 加 NVMe SSD，可搭配 10M 到 100G 的 IP Transit 頻寬彈性規劃跨區同步或多節點分散架構。更多方案細節可到 ncse.tw 參考。
