對於許多維運或後端工程師來說，「虛擬機 (VM)」就像是一個安全的沙箱，我們習慣認為 Guest OS 就算崩潰或被攻破，也不會影響到底層的 Host 主機。然而，最近披露的 Zapscape (CVE-2026-64561) 漏洞打破了這個假設。
這是一個針對 Linux KVM (Kernel-based Virtual Machine) 的嚴重漏洞，它允許在「巢狀虛擬化」環境下的 L1 Guest（第一層虛擬機）突破隔離，直接在 Host 主機上以 root 權限執行指令。
技術背景：什麼是巢狀虛擬化與 Shadow MMU？
在進入漏洞細節前，我們需要先理解兩個核心概念：
巢狀虛擬化 (Nested Virtualization) 簡單來說，就是「在虛擬機裡開虛擬機」。 L0 (Host)：實體硬體與最底層的 Hypervisor (KVM)。 L1 (Guest)：運行在 L0 之上的虛擬機，但它本身也被配置成 Hypervisor，可以運行自己的虛擬機。 L2 (Nested Guest)：運行在 L1 之上的虛擬機。
Shadow MMU (影子記憶體管理單元) MMU (Memory Management Unit) 負責將虛擬位址轉譯為實體位址。在巢狀虛擬化中，記憶體轉譯變得極其複雜（L2 $\to$ L1 $\to$ L0）。為了提升效能，KVM 使用 Shadow Page Tables (影子分頁表) 來快取這些轉譯結果，讓 L2 可以更快速地存取記憶體。管理這些表單的機制就稱為 Shadow MMU。
漏洞核心：Zapscape 的成因
Zapscape 的本質是一個 Use-After-Free (UAF, 使用後釋放) 漏洞，具體發生在 KVM 處理 Shadow MMU 簿記 (Bookkeeping) 的過程中。
故障觸發流程 當 Guest 觸發分頁錯誤 (Page Fault) 時，KVM 會進入處理路徑。漏洞出在一個名為「stale-root check」（過時根節點檢查）的順序錯誤：
檢查階段：KVM 首先檢查目前的 Shadow MMU 根節點 (Root Page) 是否仍然有效（是否 stale）。 回收階段：在檢查之後，KVM 呼叫了 make_mmu_pages_available() 來釋放一些 MMU 頁面。然而，這個回收過程可能會意外地將剛剛檢查過且認為有效的根節點給失效化 (Invalidate)。 繼續執行：由於檢查已經在步驟 1 完成，KVM 誤以為根節點仍然有效，於是繼續在該已失效的根節點下創建子分頁表 (Child Shadow Pages)。 記憶體污染：這些子分頁表繼承了失效狀態，但卻被放入了 KVM 的活動 MMU 頁面清單中。 雙重鏈結與釋放：在後續的清理過程中，同一個清單鏈結可能被掛載到兩個不同的清單上。當頁面被釋放後，仍然存在指向該頁面的「懸空指標 (Dangling Link)」。
最終，攻擊者可以利用這個懸空指標進行 Post-free Write (釋放後寫入)，從而控制記憶體內容，建構出完整的攻擊鏈。
攻擊路徑與影響
安全研究員 Hyunwoo Kim 證明了這個漏洞可以被利用來實現完整的 VM 逃逸。
攻擊權限：攻擊者必須在 L1 Guest 中擁有內核權限（通常意味著需要 L1 的 root 權限）。 實作結果：在公開的 PoC (概念驗證) 中，攻擊者能在 Host 主機上創建一個名為 /Zapscape 的 root 權限檔案。 影響範圍： * Linux 版本：Linux 5.9 及之後的版本直到被修復的穩定版本前均受影響（包括 6.6.148, 6.12.101, 7.1.6 等）。 * 硬體差異： * Intel：要求必須將 EPT (Extended Page Tables) 的 page-walk length 4 和 5 同時暴露給 L1 Guest 才能觸發。 * AMD：沒有上述限制，更容易觸發（PoC 即針對 AMD Nested SVM/NPT 測試）。
開發者與工程師應如何應對？
適用與不適用情境 高風險情境：如果你運行 KVM 主機，且將巢狀虛擬化功能開放給不可信的第三方 Guest，你處於高風險之中。 低風險情境：如果你不使用巢狀虛擬化，或者 L1 Guest 是完全受控的內部系統，風險相對較低。
實務採取做法 立即更新內核：將 KVM 主機更新至已修復的穩定版本（例如 7.1.6 或對應發行版的 backport 版本）。 檢查發行版追蹤器：注意，不要只看 Upstream 的版本號。例如 Red Hat 經常將修復補丁 backport 到舊版本中，而 Debian 的某些版本（如 bullseye, bookworm）在 8 月 6 日前仍被標記為受影響。 限制功能：在不需要巢狀虛擬化的環境中，禁用該功能以減少攻擊面。
漏洞修復機制
修復補丁 (Commit 2abd5287f083) 的邏輯非常簡單但關鍵：調整檢查順序。
修復後，KVM 將 stale-root check 移動到 make_mmu_pages_available() 之後。這樣一來，如果回收過程導致根節點失效，KVM 會立即發現，並透過返回 RET_PF_RETRY 重新啟動分頁錯誤處理流程，而不是在失效的根節點下繼續操作。
工程判斷與總結
Zapscape 再次提醒我們，虛擬化層的記憶體管理（尤其是像 Shadow MMU 這種複雜的快取機制）是極其脆弱的。
對於 Junior 工程師來說，這個案例提供了兩個重要的教訓： 檢查與執行之間的時間差 (Time-of-Check to Time-of-Use, TOCTOU)：即便你做了檢查，如果在檢查之後有任何函數（如 make_mmu_pages_available）可能改變狀態，那麼之前的檢查就失效了。 權限鏈條的重要性：雖然攻擊者需要 L1 root 權限，但在雲端環境中，如果 L1 是租戶控制的，這就等同於外部攻擊者可以直接獲取 Host 的最高權限。
雖然研究員指出此漏洞在雲端環境中尚未被「武器化」（因為需要編寫特定的內核模組並適配 Host 記憶體後端），但其潛在影響力極大，應視為高優先級的修復項目。