Linux 核心社群本週發生一起罕見的協調揭露意外 Linux kernel: unpatched ZDI bug reports with repro details leaked to public LKML (ksmbd RCE, CVSS 9.0)。台灣的趨勢科技（Trend Micro）旗下的漏洞懸賞計畫「Zero Day Initiative（ZDI）」，在 2026 年 10 月 21 日把多份尚未於正式主線（mainline）完成修補的 Linux 核心漏洞報告，除了寄給核心安全團隊的私密信箱 [email protected] 之外，疑似因作業疏失同時把公開郵件清單放進副本（Cc），包括公開的 Linux 核心郵件清單（LKML）、linux-cifs、netdev 與 dri-devel。這等於在修補尚未進入主線之前，就把漏洞細節攤在公開檔案上，其中最高的 ZDI 評分達到 CVSS 9.0。
CyberQ 指出，截至本文發稿（10 月 23 日），這批漏洞都尚未取得 CVE 編號，也沒有任何野外利用的通報。核心維護者已針對其中數項提出或指向既有修補。本文整理事件經過、各漏洞的概念層風險，以及一份系統管理者可自行照做的唯讀自我檢查清單。本文不提供任何可運作的攻擊程式或利用步驟。
一、事件經過
依 Phoronix 等媒體報導與 lore.kernel.org 郵件存檔，ZDI 在 10 月 21 日送出 5 份 Linux 核心漏洞報告，收件者是核心安全團隊，卻同時把 LKML 等公開清單放進副本。另有一份針對 ConnMan DNS proxy 的報告（ZDI-CAN-32005）在前一天先行公開，但該項屬於使用者空間程式，不屬於核心本體。
CyberQ 指出，協調揭露（coordinated disclosure）的慣例，是研究者先把細節私下交給維護者，等修補就緒、使用者有時間更新之後，才公開技術內容。所以，核心安全團隊才為此特別維護 [email protected] 這個封閉信箱。這次的問題在於，報告同時不小心寄出去進了公開清單，而對應的修補多半還沒進入任何一個已釋出的核心版本，形同把「未修補的高危漏洞細節」直接對全球公開。
開源社群大神，Linux 核心維護者 Greg Kroah-Hartman 隨後在 dri-devel 清單與對 ZDI 的回信中，公開質疑「在沒有 patch 的情況下就公開揭露」的做法，並要求 ZDI 檢討投稿流程。這也是本次事件被社群關注的主因，技術本身多數前提嚴苛，但揭露方式踩到了核心社群的紅線。
二、五份核心漏洞報告一覽
下表整理各報告的子系統、問題類型、ZDI 給出的 CVSS 分數與觸發前提。此處僅停留在概念層，不含任何利用步驟。
| 報告編號 | 子系統 | 問題類型與影響 | ZDI CVSS | 觸發前提 |
|---|---|---|---|---|
| ZDI-CAN-33774 | ksmbd | handler table 指派競態，導致遠端程式碼執行，且無需認證 | 9.0 | 主機有 ksmbd 服務在 445 埠對外，且開放 guest share |
| ZDI-CAN-33549 | ksmbd / SMB Direct | RDMA buffer descriptor 整數下溢，造成記憶體複製越界，導致遠端程式碼執行 | 9.0 | 需 RDMA 裝置、開啟 SMB Direct，且有可寫入的 share |
| ZDI-CAN-33367 | 網路 skb_zerocopy / ESP | 共享分段標記遺失，使 ESP 解密寫入 page cache 資料，導致本機提權 | 7.8 | 本機帳號，且系統開放非特權使用者命名空間 |
| ZDI-CAN-34068 | vmwgfx | dirty tracking 越界寫入，導致本機提權 | 8.8 | 僅公開標題，細節未揭露，限 VMware 虛擬機繪圖驅動環境 |
| ZDI-CAN-34076 | nvmet | Get Log Page 未初始化資源，導致資訊洩漏 | 8.6 | 僅公開標題，細節未揭露，需啟用 NVMe over Fabrics target |
三、概念層風險分析：前提決定了誰會中招
雖然帳面最高分到 9.0，但這幾項的實際暴露面高度依賴系統組態，差異很大。
兩項 ksmbd 遠端程式碼執行（33774、33549）是帳面最嚴重的，但前提也最明確，機器必須正在跑 ksmbd。ksmbd 是核心內建的 SMB 伺服器，和使用者空間的 Samba 是兩回事。多數發行版預設並不啟用 ksmbd，Debian 與 Ubuntu 雖然內建，但屬於選用，需另外安裝 ksmbd-tools 並啟動服務，AlmaLinux、CloudLinux 的 9 與 10 甚至沒有編譯 ksmbd。因此沒有對外提供核心層 SMB 分享的機器，基本上不在這兩項的射程內。ZDI-CAN-33549 又多了一層門檻，必須使用 SMB Direct（RDMA），只有同時具備 RDMA 網卡並啟用 SMB Direct 的機器才成立。
vmwgfx（34068）是 VMware 的繪圖驅動，只在 VMware 虛擬機裡才會載入，裸機或其他虛擬化平台一般不受影響。nvmet（34076）需要啟用 NVMe over Fabrics 的 target 角色，一般桌機與單純的檔案伺服器不會開。
CyberQ 認為，真正影響面最廣、最值得留意的是 skb_zerocopy 本機提權（33367），詳見下一節。
四、最普遍的風險：skb_zerocopy 與 Dirty Frag 的關係
ZDI-CAN-33367 之所以值得所有 Linux 管理者注意，在於它的前提相對寬鬆。一個本機的非特權帳號，加上系統開放非特權使用者命名空間（unprivileged user namespaces），就足以構成風險。許多現代發行版預設開啟非特權使用者命名空間，以支援 rootless 容器、Flatpak 與瀏覽器沙箱。
更關鍵的是它與 2026 年 5 月修補的 Dirty Frag（CVE-2026-43284）之間的關係。Dirty Frag 的修補，是替共享的封包分段打上標記，讓 ESP 在解密前先複製一份、避免寫壞唯讀資料。問題在於 skb_zerocopy() 這條路徑並沒有帶上該標記，於是原本的防護判斷就不會觸發。安全廠商 TuxCare 表示，即使是已套用 Dirty Frag 修補的 AlmaLinux 8、9、10 核心，在其測試環境中仍可被提權，其測試涵蓋 AlmaLinux 8/9/10、CloudLinux 9/10、Debian 12/13 與 Ubuntu 24.04/26.04，並稱繞過了 Ubuntu 的 AppArmor 非特權命名空間限制。換言之，Ubuntu 近年新增的 apparmor_restrict_unprivileged_userns 開關，已經不足以擋下這一條路徑。
但是呢，好消息是，核心網路維護者 Eric Dumazet 已表示修補很快會釋出，方向是補回遺失的共享分段標記，屬一行等級的改動，並已標記回饋到 stable 分支。ksmbd 的競態（33774）則據維護者 Namjae Jeon 表示，已在其維護樹以 commit 68f410faedaf 修正，惟尚未進入任何正式釋出，SMB Direct（33549）據稱可能已被 for-7.5/smbdirect 分支涵蓋，但此點目前未經證實。
五、社群反應
這次事件在社群引發討論的，與其說是漏洞本身，不如說是揭露方式。Greg Kroah-Hartman 對每一份公開投稿都提出質疑，核心在於「尚未有修補就公開高危細節」違背協調揭露慣例。多位維護者則在串中指出對應修補的進度，部分問題在 ZDI 公開之前，核心端其實已另有管道收到並著手處理（例如 skb_zerocopy 的同一問題，稍早已有另一位回報者私下連同 patch 寄給 netdev）。
對一般使用者而言，重點是，這幾項目前沒有 CVE、沒有野外利用通報，修補多數在途。真正該做的，是盤點自己的機器是否踩在上述前提上，並在修補釋出時盡快更新。
六、自我檢查清單與緩解
以下指令皆為唯讀，用來盤點自己的機器是否落在前述前提內。請以具備權限的帳號執行。
lsmod | grep -i ksmbd # 是否載入 ksmbd 核心模組
systemctl is-active ksmbd # ksmbd 服務是否運作
ss -ltn | grep ':445' # 445 埠是否對外監聽
ls /sys/class/infiniband/ 2>/dev/null # 是否具備 RDMA 裝置（SMB Direct 前提）
sysctl kernel.unprivileged_userns_clone # 是否開放非特權使用者命名空間
sysctl user.max_user_namespaces # 命名空間上限
lsmod | grep -iE 'nvmet|vmwgfx' # 是否載入 nvmet 或 vmwgfx
CyberQ 建議，請參考緩解方式如下。以下任何變更都請先在測試環境驗證，部分緩解尚未經官方 PoC 驗證，貿然套用可能影響既有服務。
- ksmbd：若用不到，直接停用，
systemctl disable --now ksmbd，若需要，至少先讓 445 埠不要對不信任的網路開放，等修補核心上架再恢復。 - SMB Direct：不需要 RDMA 的環境就關閉 SMB Direct，移除 ZDI-CAN-33549 的前提。
- 非特權使用者命名空間：高風險環境可考慮
user.max_user_namespaces=0，但這會影響 rootless 容器、Flatpak 與部分瀏覽器沙箱，請評估後再動，並留意 Ubuntu 的 apparmor_restrict_unprivileged_userns 已經不足以擋下本次 skb_zerocopy 路徑。 - 保持更新：skb_zerocopy 的修補已經在開發進行中，請密切關注自己發行版的核心更新，釋出後盡快套用。
