「Januscape」揭露 KVM/x86 影子分頁表通殺漏洞，Guest 可讓 Host 當機甚至提權
GitHub（資安研究專案，作者 Hyunwoo Kim）· 2026-07-06
資安研究者 Hyunwoo Kim 於 2026 年 7 月 6 日公開名為 Januscape 的研究專案，揭露 Linux KVM/x86 虛擬化子系統中一個被編號為 CVE-2026-53359 的 use-after-free 瑕疵。攻擊者只要在客體虛擬機（guest）內執行程式碼，就能腐化宿主機（host）核心維護的影子分頁表，進而讓 host kernel panic，或以 root 權限在 host 上執行任意程式碼。作者稱這是第一個同時可在 Intel VT-x 與 AMD-V 兩種硬體虛擬化架構上觸發的 guest-to-host escape 研究，而非侷限單一平台的特例。
漏洞機制
問題根源在 arch/x86/kvm/mmu/mmu.c 的 pte_list_remove 函式。當硬體不支援 EPT/NPT，或在特定巢狀虛擬化情境下，KVM 會退回用純軟體維護的影子分頁表（shadow page table）來模擬 guest 的分頁結構：每個 guest 實體頁框（PFN）可能同時被多筆 shadow PTE 反向映射（rmap）指向，KVM 需要一份鏈結串列追蹤這些反向映射項目。
Januscape 展示的手法是單靠 guest 端的操作就讓這份 rmap 串列在核心裡出現懸空參照，隨後對已釋放的節點進行讀寫，達成 host 記憶體腐化。由於整個觸發過程完全發生在 guest 可控的路徑上，不需要任何 host 端協作或額外硬體條件，攻擊面因此涵蓋所有啟用 KVM 的多租戶雲端環境。
受影響版本
這個瑕疵存在時間跨度極長，從 2010 年就已埋入核心程式碼：
- 引入缺陷的提交：
2032a93d66fa（2010-08-01） - 修補提交：
81ccda30b4e8（2026-06-16） - 跨越約 16 年的 Linux 核心版本
影響分兩類：一是標準的 KVM escape，具備 guest 存取權的攻擊者可讓 host 核心當機（DoS）或以 root 權限執行程式碼；二是在 /dev/kvm 權限被放寬為 world-writable（如部分 RHEL 系發行版的預設設定為 0666）的主機上，本機非特權使用者可藉此穩定提權至 root。研究同時提及一個相關但獨立的漏洞 ITScape（CVE-2026-46316），影響 arm64 架構的 KVM，需另行修補。
修補與緩解
漏洞循負責任揭露流程回報至 linux-distros@vs.openwall.org，禁運期滿後於 oss-security 郵件論壇公開。該漏洞也被成功武器化為 0-day，並在 Google 的 kvmCTF 競賽中實際攻破，證明其可利用性並非僅止於理論。
PoC 是一個載入 guest 內核心模組（poc.c），需要 guest root 權限；Intel 平台執行時不需參數，AMD 平台則需加上 amd=1 參數，公開的 PoC 版本會在數秒至數分鐘內讓 host 核心 panic，展示的是 DoS 而非完整的程式碼執行鏈。緩解方式為升級至包含 81ccda30b4e8 修補的核心版本，並在多租戶環境中審視 /dev/kvm 的存取權限設定，避免非特權使用者可直接開啟裝置節點。
原始來源：Januscape（GitHub）
uutils coreutils 一次修三個資安洞：cut 靜默漏篩選、mknod 貼錯 SELinux 標籤、mkfifo 誤改敏感檔案權限
GitHub Advisory Database · 2026-07-06
2026 年 7 月 6 日，GitHub Advisory Database 同時公布三則 uutils/coreutils（Rust 重寫版 GNU coreutils）的安全性通告：CVE-2026-35381、CVE-2026-35361、CVE-2026-35341。三者皆源自 Zellic 於 2026 年 1 月替 Canonical 進行的 uutils coreutils 資安評估，分別影響 cut、mknod、mkfifo 三個工具的行為正確性與安全性，其中一項屬高風險等級。
CVE-2026-35381：cut -s 在 NUL 分隔模式下被繞過
GHSA-pmfc-4wjj-gmhx 指出，當使用者以 -z -d '' 組合（NUL 位元組作為記錄分隔符、空字串作為欄位分隔符）呼叫 cut 時，程式會把整個請求導向一條特殊的換行分隔路徑，這條路徑完全忽略了 -s（只輸出含分隔符的記錄）旗標。結果是即使指定 -s，仍會把不該輸出的整筆未分隔記錄印出，可能造成資料過濾遺漏。此問題影響 < 0.7.0 版本，於 0.7.0 修補（CWE-684，CVSS 3.3，低風險），修補見 PR #11394，提交 483f13e91830c468262aa1e010e753d6ae99c898。
CVE-2026-35361：mknod 建立裝置節點時 SELinux 標籤時序錯誤
GHSA-r9hw-mj3w-phcq 描述的問題是uutils 的 mknod 先呼叫 mknod() 建立節點，之後才嘗試設定 SELinux context，而 GNU coreutils 的正確做法是先呼叫 setfscreatecon 讓核心以正確標籤原子性地建立節點。一旦事後補標籤失敗，uutils 的錯誤清理邏輯呼叫 std::fs::remove_dir 嘗試刪除節點，但該函式無法刪除裝置節點或 FIFO 檔案，於是留下標籤錯誤的孤兒節點殘留在系統上，可能繞過 SELinux 的強制存取控制，且能在重開機後依然存在。影響 < 0.6.0，於 0.6.0 修補（CVSS 3.4，低風險），修補見 PR #10582，提交 42b2ad83cdcf6e959ecb378c5040c60d9c64becf，建議做法為改用 setfscreatecon 並在失敗時直接中止，清理時改用 remove_file。
CVE-2026-35341：mkfifo 建立失敗後仍誤改既有檔案權限
GHSA-pmf6-rcx4-v53v 是三者中風險最高的一項。當目標路徑已存在檔案導致 FIFO 建立失敗時，程式雖然印出錯誤訊息，但程式碼漏了一個 continue 陳述式，導致流程繼續往下執行到 fs::set_permissions，把該既有檔案的權限強制改成 FIFO 預設模式（umask 套用後為 0644）。官方通告舉例：攻擊者（或使用者誤用）可藉此放寬如 SSH 私鑰等僅限擁有者存取的敏感檔案權限，使其他本機使用者也能讀取。影響 < 0.6.0，於 0.6.0 修補（CVSS 7.1，高風險），修補見 PR #10376，對應追蹤 issue #10020，修法即是在錯誤處理後補上 continue，阻止流程落入權限修改分支。
| CVE | 元件 | 機制摘要 | 嚴重性 | 受影響版本 | 修補版本 |
|---|---|---|---|---|---|
| CVE-2026-35381 | cut | -z -d '' 模式下 -s 旗標失效 | 低（3.3） | < 0.7.0 | 0.7.0 |
| CVE-2026-35361 | mknod | SELinux 標籤時序錯誤、清理失敗 | 低（3.4） | < 0.6.0 | 0.6.0 |
| CVE-2026-35341 | mkfifo | 建立失敗後仍誤改既有檔案權限 | 高（7.1） | < 0.6.0 | 0.6.0 |
修補與緩解
三個問題已分別於各自的修補版本解決，官方後續版本（含 0.8.x 系列）已整合全部三項修補，建議直接升級到當前穩定版而非只挑單一修補版本。對於部署 SELinux 強制模式的環境，需額外檢查是否已有歷史遺留的錯誤標籤裝置節點需要手動清理；對於曾用受影響版本執行過 mkfifo 且該次呼叫失敗過的系統，應覆核相關路徑上既有檔案的權限是否被意外放寬，尤其是私鑰、憑證等敏感檔案。
原始來源：GHSA-pmfc-4wjj-gmhx、GHSA-r9hw-mj3w-phcq、GHSA-pmf6-rcx4-v53v
crossbeam-epoch 修補指標格式化崩潰漏洞，Rust 無鎖資料結構生態圈受牽連
RustSec Advisory Database · 2026-07-06
RustSec Advisory Database 於 2026 年 7 月 6 日發布 RUSTSEC-2026-0204，指出 Rust 生態圈中被廣泛依賴的無鎖記憶體回收套件 crossbeam-epoch 在 0.9.0 至 0.9.19 版本中，其 Atomic 與 Shared 型別的 fmt::Pointer（對應 fmt::Display）實作會直接解參考底層指標。當指標為 null 或已失效時，格式化該值就會導致程式崩潰。修補版本 0.9.20 已發布。
漏洞機制
crossbeam-epoch 是 crossbeam 生態圈中實作基於 epoch 的記憶體回收（epoch-based reclamation）的核心套件。無鎖（lock-free）資料結構如並行跳躍表（skip list）或並行佇列在移除節點時，不能立即釋放記憶體，因為其他執行緒可能仍持有指向該節點的裸指標並正在讀取；epoch-based reclamation 的做法是維護一個全域 epoch 計數器，只有當所有執行緒都確認離開了節點被移除當下的 epoch，才判定該節點可以安全回收。crossbeam-epoch 提供 Atomic<T> 與 Shared<'g, T> 兩個型別包裝這類受 epoch 保護的指標，供上層資料結構使用。
為了方便除錯，crossbeam-epoch 也為這兩個型別實作了標準函式庫的 fmt 系列 trait。問題出在 0.9.0 起新增的 fmt::Pointer（對應 {:p} 格式化）與同版起的 fmt::Display 實作：這兩者會對指標做 unsafe 解參考，印出指標所指向的值本身，而不只是位址。一旦被格式化的是尚未指向任何物件的 Atomic::null()，或是已經被回收、生命週期已過期的懸空指標，解參考就會觸發 segfault 或未定義行為。相對地，fmt::Debug 實作以及 0.9.0 之前版本的 fmt::Display 實作只印出指標位址，不做解參考，因此不受影響。
受影響版本與觸發條件
- 受影響：
0.9.0至0.9.19 - 不受影響：
< 0.9.0（尚未實作解參考版本的 Display） - 已修補：
>= 0.9.20
此漏洞屬於需要呼叫端主動觸發的格式化路徑：只有當程式明確以 {}（Display）或 {:p}（Pointer）格式化 Atomic 或 Shared 值時才會出事，預設的 {:?}（Debug）輸出不受影響。多數上層資料結構在正常執行路徑中不會格式化這些內部指標型別，因此實際觸發通常出現在除錯輸出、日誌記錄或直接使用 crossbeam-epoch 底層 API 撰寫並行資料結構的場景。
修補與緩解
修補由 GitHub PR #1276 提出，回退 Display/Pointer 實作為只印位址、不解參考的安全版本，並已隨 0.9.20 釋出。由於 crossbeam-epoch 是 crossbeam 系列並行資料結構套件的底層依賴，受影響版本區間可能透過多層傳遞依賴被間接引入專案，建議以 cargo update -p crossbeam-epoch 或執行 cargo audit 確認鎖定檔中的實際版本並升級。此次修補範圍僅止於格式化實作，未觸及 epoch 追蹤或實際記憶體回收邏輯，因此不影響仰賴其做無鎖回收的資料結構（如工作竊取佇列）本身的正確性，但只要程式碼路徑會格式化這些指標型別，就應視為需要修補的記憶體安全問題。
原始來源：RUSTSEC-2026-0204