前言

昨天才整理完 GitLab、PHP、Node.js、Java、Go 與 Railway，接著又看到「Linux 核心多項漏洞公開、最高 CVSS 9.0」的消息。對管理 NAS、Linux 伺服器或 Kubernetes 的人來說，接下來要確認的是：自己的主機有沒有啟用相關元件，修補又走到哪個階段？

這篇承接前一篇十月資安事件總整理，追蹤這批 Linux 通報，並補上 ConnMan DNS proxy 與 LiteLLM 1.107.0 供應鏈入侵。三者分別涉及核心、使用者空間服務與套件發行流程，維護時需要找到各自的負責層級。

查核截點：2026-10-23 08:25，台灣時間 UTC+8。 本文依公開通報、維護者回覆與官方事件說明整理；受影響版本、發行版回移修補與調查結論仍可能更新。文中的指令為唯讀盤點範例，未在讀者環境執行。封面是 AI 生成的概念插畫：紫色紙板櫃的開口與紅色紙帶連向共用底座，呈現不同入口對共用設施的影響。

一、Linux 這次發生什麼事？

10/21，Trend Micro Zero Day Initiative（ZDI）送出了多份 Linux 漏洞報告；收件資訊包含公開郵件清單，內容也出現在可公開閱讀的封存站。例如 KSMBD 的 SMB Direct 通報，同時寄給 [email protected] 並副本給 linux-cifs、linux-kernel 等清單。原始通報

核心維護者 Greg Kroah-Hartman 隨後詢問，為何報告送到公開清單，以及為何沒有附修補。後續討論也涉及報告品質、測試與協作流程。能確認的是通報已公開；是否屬於誤寄，不能光從新聞標題下定論。維護者回覆、後續協作討論

先看這次需要盤點的項目。分數採 ZDI 清單上的 CVSS v3.0 評估；它描述通報的嚴重程度，實際優先序還要配合服務是否啟用、攻擊者是否可達。

追蹤編號／事件 元件與通報影響 ZDI 分數 先找哪些環境？
ZDI-CAN-33549 KSMBD SMB Direct 整數下溢，通報為遠端程式碼執行（RCE） 9.0 使用 KSMBD、SMB Direct／RDMA 與可寫入共享的檔案伺服器
ZDI-CAN-33774 KSMBD 協定分派競爭條件，通報為 RCE 9.0 啟用 KSMBD 的主機，尤其有訪客可存取共享的配置
ZDI-CAN-33367 skb_zerocopy 共用資料所有權處理不完整，本機權限提升 7.8 可執行不受信任程式的多使用者主機、CI worker、容器節點
ZDI-CAN-34068 vmwgfx dirty tracking 越界寫入，本機權限提升 8.8 使用 VMware 虛擬顯示驅動的 Linux 環境
ZDI-CAN-34076 nvmet Get Log Page 使用未初始化資源，資訊洩漏 8.6 提供 NVMe target 功能的儲存伺服器
ZDI-CAN-32005 ConnMan 內部 DNS proxy 堆疊緩衝區溢位，通報為本機權限提升 7.8 使用 ConnMan 內部 DNS proxy 的系統
LiteLLM 1.107.0 PyPI wheel 與容器產物遭植入竊密、遠端載入程式 不適用 在受污染時段取得相關產物的開發機、CI、AI Gateway

分數與通報日期來源：ZDI Upcoming Advisories。技術細節分別見下文原始郵件；LiteLLM 為官方確認的發行流程入侵事件。

這裡的 ZDI-CAN-xxxxx 是 ZDI 的候選案件編號。本文保留原始編號方便追蹤，未替它們填入尚未核實的 CVE 對照；Linux 的修補流程本身也不要求先取得 CVE 才能處理。Linux 安全通報文件

二、兩個 9.0 的 KSMBD 問題，誰比較需要緊張？

要判斷影響，先認清自己使用的 SMB 實作。SMB 是檔案共享協定，Linux 上可以有不同的伺服器與用戶端。

KSMBD、Samba、SMB 用戶端要分清楚

KSMBD 是在 Linux 核心內實作檔案操作的 SMB 伺服器，另由 ksmbd.mountd 處理部分使用者空間工作。它啟動後會接收 SMB 連線，並把請求交給核心 worker 處理。Linux KSMBD 架構文件

因此，盤點時至少要分辨三種情境：

  • 使用 ksmbd 提供共享：直接核對這兩項通報。
  • 使用使用者空間的 Samba smbd：確認實際套件與服務，不能直接套用 KSMBD 的漏洞結論。Samba 服務文件
  • 只透過 CIFS／SMB 掛載別人的共享：目前看到的兩份報告針對伺服器路徑，仍應依元件確認適用性。

NAS 也要查廠商採用的實作、韌體與公告。同一款設備是否使用 KSMBD、是否開啟 RDMA，不能從「支援 Windows 檔案共享」這個規格推論。

ZDI-CAN-33549：SMB Direct 的長度計算出了問題

這份報告描述 smbdirect_connection_rdma_xmit() 的整數下溢：處理緩衝區描述資訊時，剩餘長度被錯誤扣減，可能進一步造成核心堆積記憶體越界寫入。報告列出的測試核心是 7.3-rc3，並要求 RDMA 裝置、可寫入共享與 SMB Direct 路徑。通報與測試條件

這些條件很有實務意義。沒有提供這項服務的 API 主機，與正在使用 SMB Direct 的儲存主機，需要安排的工作會不同。另外，測試配置包含軟體 RDMA RXE，所以盤點不能只查是否安裝實體 RDMA 網卡。

修補進度也要說準：Stefan Metzmacher 的回覆是請研究者測試 for-7.5/smbdirect 開發分支，並表示他認為問題可能已在其中修好。這是待驗證的分支資訊，還不能當成「所有使用者已可取得正式修補」的公告。維護者回覆

ZDI-CAN-33774：排入佇列與實際處理時，協定狀態不一致

另一份報告描述的是競爭條件：請求先排入工作佇列，但連線使用的協定操作介面可能被後續請求改變，導致 worker 用錯誤的解析方式處理先前的緩衝區。報告指出越界讀取、資訊洩漏與越界寫入路徑，並列出競爭條件與訪客共享的觸發要求，測試核心同為 7.3-rc3。原始分析

10/22，KSMBD 維護者 Namjae Jeon 已回覆對應修補，指向 commit 68f410faedaf。維護者回覆

這個 commit 的做法，是在協商階段等待已排入的工作完成，再讀取下一個協定資料單元（PDU），讓處理先前請求時使用的協定狀態維持一致。這也說明競爭條件的修正重點：需要保護整段狀態轉換與工作執行的關係。修補 commit

實務上，提供 KSMBD 的主機應優先限制服務可達範圍；若業務允許，可暫停相關共享或功能，再依發行版／設備廠商公告恢復。修改訪客或寫入設定只能算縮減已知觸發條件，完整修補仍要追蹤套件與核心。

三、其他核心通報：本機提權、虛擬顯示與儲存服務

其餘幾項涉及不同信任邊界。關閉對外 SMB 入口後，仍需要依主機用途繼續盤點。

skb_zerocopy：只有讀取權限的檔案，資料仍可能被改動

ZDI-CAN-33367 涉及封包資料在零複製傳遞時，保留了共用頁面的參照，卻遺失描述共用所有權的標記。後續處理可能把共用資料當成可以原地改寫的私有資料。通報展示的結果是：本機非特權程式能修改原本只能讀取的檔案所對應的資料。原始通報

這份重現涉及使用者／網路命名空間、NFQUEUE 與 ESP 等組合；不能只根據「network code」就寫成遠端封包直接取得 root。對可執行不受信任程式的環境，應進一步核對命名空間、能力權限與核心配置是否使相關路徑可達。

Eric Dumazet 在 10/22 回覆中表示，團隊前一週已從另一來源收到附修補的相同問題，修補將公開。這是本文已查到的具體進度；尚未核實的發行版修正版不填入表格。維護者回覆

vmwgfx 與 nvmet：先確認驅動和服務是否存在

ZDI-CAN-34068 的通報標題是 vmwgfx Dirty Tracking 越界寫入與本機權限提升；ZDI-CAN-34076 則是 nvmet Get Log Page 使用未初始化資源造成資訊洩漏。兩者在維護者公開回覆中都有對應記錄。vmwgfx 回覆、nvmet 回覆

盤點時，前者要找使用相關虛擬顯示驅動的 Linux 系統；後者要找提供 NVMe target 服務的儲存節點。裝有 NVMe SSD，不代表正在提供 nvmet 服務。 同樣地，這些通報不足以直接證明 VMware hypervisor 已遭攻陷，或所有 VMware 虛擬機都能逃逸到宿主機。

四、ConnMan 要另外追：它是使用者空間服務

有一項常被跟這批 Linux 消息一起列出：ZDI-CAN-32005。ZDI 官方清單將產品列為 ConnMan，通報給廠商的日期為 10/19；公開郵件則標示 10/20 UTC。這幾個日期代表不同節點。ZDI 清單、ConnMan 原始郵件

通報測試的是 ConnMan 2.0 的內部 DNS proxy。在設定 DNS search domain 後，轉送替代查詢時，請求長度與固定大小的堆疊緩衝區檢查不完整，可能造成溢位。它歸在本機權限提升；不能把郵件中的測試版本當成完整受影響範圍。

還有一個值得保留的限制：報告展示控制執行流程時，使用了關閉部分保護的除錯建置。因此，正式環境的可利用性必須再對照編譯保護、DNS backend 與服務配置，不能把該示範直接寫成所有正式安裝都可穩定取得 root。通報的分析與重現條件

使用 ConnMan 的設備需要追蹤 ConnMan 套件／韌體；核心更新的完成紀錄無法代替這項工作。

五、現在到底修好了沒？追蹤四個交付節點

截至本文截點，已核對到部分維護者回覆與修補來源，但未取得這批案件在各發行版、各分支上的完整固定版本對照。因此，這裡提供可追的證據，讓管理者拿自己的套件版本向供應商確認。

案件 已查到的具體進度 維運端仍要確認
ZDI-CAN-33549 維護者請研究者測試 for-7.5/smbdirect 分支，認為可能已修正 驗證結果、最終 commit、適用分支與廠商套件
ZDI-CAN-33774 維護者指出 68f410faedaf 修補；已核對 commit 內容 是否進入所用的核心分支／發行版，以及主機是否已載入修補
ZDI-CAN-33367 維護者表示先前已收到另一份附修補的通報 最終修補與發行版公告
vmwgfx／nvmet／ConnMan 已確認對應通報、元件與 ZDI 分數 完整版本範圍、正式修補或廠商暫解措施

來源為前文各案的原始郵件與 commit。通報中測試過 7.3-rc1 或 7.3-rc3，只能證明該測試配置出現問題；既不能推成所有 Linux 版本都受影響，也不能推成只有測試版本受影響。

對正式環境，我會把完成條件記成四個交付節點：

flowchart TD
    A[維護者確認問題與修補] --> B[修補進入適用的主線或 stable 分支]
    B --> C[發行版或設備廠商交付修補套件]
    C --> D[安裝並啟用修補後的核心或服務]
    D --> E[核對實際運行版本與公告涵蓋範圍]

發行版也可能直接回移修補，路徑不一定嚴格依序。重點是留下 案件編號、修補 commit、廠商公告、套件版本、運行狀態的對照。套件版本號看起來較舊，也可能已含回移修補；只看上游大版本很容易誤判。

公開通報與大量 AI 報告，還有協作成本

Linux 官方目前的通報文件要求明確版本、可重現資訊與觸發條件，也鼓勵提供測過的修補；對容易由 AI 工具重複發現的問題，另有公開處理與重現資訊的規定。Linux 安全通報流程

這能幫助理解後續討論為何同時出現「請附修補」「請讓研究者協助測試」與「為何寄到公開清單」。對讀者最有用的，是持續追蹤問題是否確認、補丁是否有效，以及正式套件何時可用；無法僅憑這些討論判斷每一案都由 AI 發現，或每一份通報都有同等影響。

六、實務盤點：Linux、NAS 與容器分別查什麼？

先收集運行資訊，再對照公告。以下都是唯讀範例，依權限、發行版與工具安裝情況調整；它們不會自動判定是否存在漏洞。

Linux 主機：版本、模組、服務與入口一起看

在需要盤點的 Linux 主機上，可先查看：

1
2
3
4
5
6
7
8
# 目前運行中的核心、發行版與已載入模組
uname -r
cat /etc/os-release
lsmod | rg '^(ksmbd|vmwgfx|nvmet|rdma_rxe)\b'

# 監聽端點，以及常見服務名稱的狀態
ss -lntup
systemctl status ksmbd.service connman.service --no-pager

解讀時保留幾個限制：

  • lsmod 只列可載入模組，編進核心的功能不會以相同方式出現在清單；必要時核對運行核心對應的配置檔。
  • 服務單元名稱可能不同；也可能由 NAS 管理程式、自訂腳本或其他方式啟動。
  • 開啟 445 埠只能證明有相關入口，還要辨識究竟由誰處理；RDMA 也要查實際傳輸與網路路徑。
  • uname -r 顯示運行版本，安裝紀錄顯示磁碟上的套件。兩者要與發行版公告交叉比對；使用 livepatch 時另核對該案是否被涵蓋。

若這是公司 NAS，最直接的交付物是：型號、韌體、SMB 實作、共享權限、可達網段，以及廠商修補狀態。暫停共享會影響使用者，應按既有維護流程安排。

Docker／Kubernetes：核心修補需要落到節點

一般 Linux 容器的隔離依靠主機核心提供的 namespaces、cgroups 等機制；容器權限配置也會影響核心功能是否可達。Docker 安全文件

因此，重建應用映像檔時，還需要另外確認承載它的節點核心。若是一般虛擬機，guest 核心要在 guest 內更新；若使用沙箱或 VM 型容器執行環境，則按其實際隔離邊界盤點。

Kubernetes 的 Node 資訊包含核心與作業系統版本，可以先列出節點回報的內容：

1
kubectl get nodes -o custom-columns='NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage'

這個清單適合分派更新工作，仍需配合廠商公告確認補丁。一般更新流程可以整理成：

flowchart TD
    A[盤點節點核心與啟用功能] --> B[取得供應商確認的修補版本]
    B --> C[準備容量並依維護流程移轉工作負載]
    C --> D[更新或替換節點並啟用修補]
    D --> E[確認節點運行版本與服務健康]
    E --> F[逐批完成其餘節點並留下紀錄]

實際操作要考慮 PodDisruptionBudget、狀態型服務、儲存與可用容量。雲端代管叢集也要分清控制平面、worker node 與 node image 的維護責任。

七、另一件要補追的事：LiteLLM 1.107.0 發行產物遭植入惡意程式

這幾天使用 AI Gateway、Python SDK 或 AI 開發工具的團隊，還應盤點 LiteLLM。官方確認 10/21 發行流程遭入侵，1.107.0 的 PyPI wheel 與容器產物帶有竊密及遠端程式碼載入功能。本文引用的官方調查版最後標示更新為 10/21 20:30 UTC（台灣 10/22 04:30），狀態為已圍堵、調查持續中。LiteLLM 官方事件報告

受污染時段：PyPI、Docker Hub 與 GHCR 分開核對

以下依官方時間軸換算為台灣時間。時間代表當時可取得受污染產物的窗口；下載快取、私有鏡像與後續啟動仍可能延長內部暴露時間。

發行管道 確認受影響產物 2026/10/21 UTC 台灣時間 UTC+8
PyPI litellm==1.107.0，7 個 wheel 11:39:51～13:23 19:39:51～21:23
Docker Hub v1.107.0、latest、main-latest、main-stable 11:46:56～14:20 19:46:56～22:20
GHCR 同組標籤，含不同映像檔變體 11:46:56 起，至 13:51 已驗證不可取得 19:46:56 起，至 21:51 已驗證不可取得

來源：官方確認範圍與時間軸。官方指出私有企業 registry 的發布未受此次污染；實際仍以團隊取得產物的管道判斷。

官方列出的受污染主要 image index 為：

1
sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e

這只代表其中一個索引，其他變體還有自己的 digest。多平台 image index 與單一平台 manifest 也可能呈現不同識別值，要配合 registry、建置紀錄與原始完整指標核對。Datadog 原始分析與指標

latest 等標籤後來已改回乾淨來源，因此只看今天同一標籤的內容，無法證明昨天執行過的映像檔安全。

為什麼連 pip show 都可能再次觸發？

JFrog 的分析指出，惡意 wheel 會把 cook.pth、cook.py、sitecustomize.py 放入環境的 site-packages 根目錄，使用 Python 啟動機制執行。JFrog wheel 分析

Python 一般啟動時會處理 site 初始化，其中包含可執行的 .pth 設定與 sitecustomize 載入機制。因此，即使沒有 import litellm，一般 Python 啟動也可能觸發惡意程式，包括以 Python 執行的管理工具。Python 啟動設定文件

已分析的目標包含雲端憑證、SSH 與開發工具機密、環境變數，以及 LiteLLM proxy 資料庫中的上游模型供應商金鑰。影響範圍可能擴及該執行身分可讀、可取得的資源。Windows 的遠端載入分支有執行限制，但竊密啟動路徑仍需處理。JFrog 竊密範圍分析

盤點時可從可信任的 shell／調查環境檢查檔案、已保存的套件 metadata、建置紀錄與映像檔資訊。不要先在可疑虛擬環境啟動 Python 或 pip。sitecustomize.py 本身也可能有合法用途，需比對內容、檔案來源與其他指標，不能看到檔名就刪除。

原始碼乾淨、有簽章，仍要核對實際建置來源

官方指出 GitHub 的 v1.107.0 原始碼 tag 沒有這些惡意檔案；調查描述攻擊者使用開發者憑證，修改發布工作流程，將來源指向名稱近似的另一個 repository。Datadog 也分析了建置來源與產物的落差。官方調查進度、Datadog 建置來源分析

這次帶來的工程提醒是：簽章與來源證明需要搭配來源政策驗證。若遭入侵的流程仍可合法簽署，驗證方還要確認來源 repository、commit、工作流程與發布權限是否符合預期。

至於開發者憑證如何外洩，官方提出內部 LiteLLM 部署與日誌的調查線索，也明確表示最初存取方式尚未確認。這部分應繼續標記為調查中；目前沒有充分依據把它與 Linux、Railway 或其他事件歸為同一攻擊來源。

已經執行過受污染產物，怎麼處理？

下列是依官方處置與原始分析整理的維運順序，應由負責團隊依事件應變流程執行：

  1. 隔離環境並保存證據：保留映像檔識別、套件檔案、安裝與執行時間、網路及稽核紀錄。
  2. 停止可疑程序，從可信任來源重建：同時處理開發虛擬環境、CI 快取與內部鏡像，避免再次散布相同產物。
  3. 從乾淨環境撤銷與輪替暴露的機密：包含雲端角色可取得的憑證、模型供應商 API key、資料庫密碼、發布與原始碼平台 token。
  4. 調查外洩憑證是否被使用：對照雲端與原始碼平台稽核紀錄；AWS 環境可依官方建議追查相關身分活動。

官方當時建議固定到 1.106.2 或此前明確版本，並優先重建環境。但版本回退只處理產物，已被取得的憑證還需要撤銷；正式選版也要繼續追蹤後續安全公告。官方處置建議、Datadog 建議

也別因為找不到暫存標記檔就結案。官方與研究分析都提醒，暫存目錄清理、容器重建等行為會讓證據消失，缺少單一指標不能證明未曾暴露。

八、這次我會怎麼排工作？

以下是依暴露條件提出的工程判斷，適合拿來分派負責人；實際期限仍需配合自己的可達範圍、資料敏感度與服務重要性。

觀察到的情況 優先工作
曾安裝受污染的 LiteLLM wheel，或執行受污染容器 啟動事件應變、隔離與保存證據、乾淨重建、撤銷／輪替可觸及的機密
提供可達的 KSMBD 共享，尤其有訪客、寫入或 RDMA 條件 縮減服務入口與功能，向供應商核對修補，安排更新
多使用者、CI 或其他可執行不受信任程式的 Linux 主機 優先查本機提權通報適用性、核心配置與更新狀態
使用 vmwgfx、nvmet 或 ConnMan 特定功能 分派虛擬化、儲存或設備維護者查元件與廠商公告
尚未確認是否使用相關元件 先完成資產與配置盤點，保留公告比對結果，再決定維護範圍

這份追蹤也補上前篇的一個層次：我們需要維護的包含主機核心、服務套件、容器產物、套件發布鏈與機密權限。每完成一層，都留下可核對的證據，才能在下一篇公告出現時知道還有哪些工作。

總結

Linux 這批通報確實值得追，其中兩個 KSMBD 案件由 ZDI 評為 9.0；影響判斷要落到實際啟用的伺服器、RDMA、共享設定與核心功能。部分問題已有維護者修補來源，接下來要確認的是它如何交付到自己的發行版、NAS 與運行中的節點。

同時，ConnMan 應追套件更新；LiteLLM 則需要檢查取得與執行過的發行產物，受影響時搭配事件應變與機密處理。把元件、條件、產物與交付狀態查清楚，團隊就能把這一串新聞變成可完成的維護工作。

延伸閱讀

主要查核資料