Zapscape：KVM 影子分頁少一道引用計數檢查，讓惡意租戶跳出虛擬機器
oss-security 郵件列表 · 2026-08-06
這是一個藏在 Linux KVM/x86 影子記憶體管理單元（shadow MMU）裡的 use-after-free 漏洞，編號 CVE-2026-64561，研究者稱之為 Zapscape。攻擊者只要能在客體虛擬機（guest VM）內執行一般權限的程式碼，就能觸發一段影子分頁被提前釋放又被存取的競態，從客體逃逸並取得主機（host）控制權。這對接受不受信任租戶、又開啟巢狀虛擬化（nested virtualization）的多租戶雲端環境是直接威脅。
漏洞機制
當主機開啟巢狀虛擬化，允許客體內再跑一層 hypervisor（L1）去啟動更內層的 guest（L2）時，如果硬體無法直接疊合兩層位址轉換，KVM 就得用軟體把 L1 的分頁表和主機分頁表疊合成一份「影子分頁表」（shadow page table），交給實體 MMU 使用。這些影子分頁在被系統回收、清除（zap）時，程式碼會沿著結構遞迴走訪並釋放子項。問題出在 mmu_page_zap_pte() 這段遞迴清除路徑：官方公告原文寫成「recursive zap without a root_count guard → active_mmu_pages use-after-free」，也就是清除前沒有檢查該影子分頁的 root_count（是否仍有作用中的 root 在參照它），導致一份仍在使用中的頁面被提前釋放，形成 UAF 窗口。攻擊者可在窗口內用精心佈局的記憶體配置搶佔被釋放的空間，進一步取得任意讀寫甚至程式碼執行能力。
觸發條件依平台而異：在 Intel 平台上，必須同時把 EPT 的 4 層與 5 層分頁走訪（page walk length 4 和 5）都暴露給 L1 才能命中；AMD 平台則沒有這層架構限制，可觸發範圍更廣。
受影響版本
受影響的程式碼路徑自 2020 年被引入後就一直存在，直到近期才被修補：
- 起始 commit：
f95eec9bed76（2020-07-08） - 修補前最後一個受影響狀態：
2abd5287f083之前的所有 mainline kernel（截至 2026-07-21）
修補與緩解
修補已合入 mainline，commit 2abd5287f083 為遞迴清除路徑補上 root_count 驗證，避免仍被參照的影子分頁被提前釋放。此漏洞經由 security@kernel.org 負責任揭露後修補。概念示意如下：
// 概念示意：遞迴清除影子分頁時遺漏 root_count 檢查
static void mmu_page_zap_pte(struct kvm *kvm, struct kvm_mmu_page *sp)
{
zap_child_shadow_pages(kvm, sp); // 遞迴清除子項
// 缺少：if (sp->root_count) return; // 仍有 root 參照，不可釋放
free_mmu_page(kvm, sp); // active_mmu_pages 提前釋放 → UAF
}對多租戶雲端環境而言，AMD 主機因無架構限制而風險較高，應優先確認 kernel 是否已包含修補 commit；開啟巢狀虛擬化功能的環境應視為高優先升級對象。
原始來源：oss-security：Zapscape: Guest-to-Host Escape in KVM/x86 (CVE-2026-64561)
刪一個 IP 位址就能奪權：Linux SCTP ASCONF 處理程序的釋放後重用漏洞
oss-security 郵件列表 · 2026-08-06
Linux 核心 SCTP 協定堆疊處理 ASCONF（動態位址重新配置）的程式碼存在 use-after-free 漏洞，編號 CVE-2026-64564。本機低權限使用者只要能開一條 SCTP 連線，依序送出兩個構造過的 ASCONF 指令，就能讓核心存取一個已釋放的 transport 結構，達成本機權限提升到 root；在容器環境中，由於 SCTP 協定堆疊是 host kernel 共用資源，同樣手法可直接突破容器隔離拿下 host 的 root 權限。
漏洞機制
RFC 5061 定義的 ASCONF chunk 讓 SCTP 連線建立後可以動態新增或刪除自己的 IP 位址，不必中斷連線，其中 DEL-IP 參數負責「刪除位址」，由核心的 sctp_process_asconf() 處理。漏洞觸發分兩步：第一步送出一個 DEL-IP，目標位址刻意設成「不是」該封包的來源位址，這樣可以通過驗證檢查，但會釋放掉 asconf->transport 快取的 transport 物件——公告原文指出根因是「cached transport may differ from the transport associated with the packet's source address」，也就是快取的 transport 與封包來源位址實際對應的 transport 可能是兩個不同物件，兩者的生命週期沒有被正確同步。
第二步再送出一個 wildcard DEL-IP（目標位址設為 0.0.0.0），這次處理路徑會在 sctp_assoc_set_primary() 與 sctp_assoc_del_nonprimary_peers() 中重新用到第一步已經釋放掉的懸空指標，形成 UAF。攻擊者可在這個窗口用可控資料重新佔用釋放掉的記憶體，進而劫持核心控制流。
// 概念示意：兩階段 ASCONF 觸發 UAF
// 第一步：DEL-IP 目標非來源位址，通過檢查但釋放 transport
asconf1 = build_asconf(DEL_IP, addr=非來源位址);
sctp_process_asconf(asoc, asconf1);
// → 釋放 asconf->transport 所指向的 transport 物件
// 第二步：wildcard DEL-IP 重用已釋放的指標
asconf2 = build_asconf(DEL_IP, addr=0.0.0.0);
sctp_process_asconf(asoc, asconf2);
// → sctp_assoc_set_primary() / sctp_assoc_del_nonprimary_peers()
// 存取懸空指標，觸發 use-after-free受影響版本
問題程式碼自 2.6.25（commit 42e30bf3463c）就已存在，研究團隊實測以下發行版皆可觸發：
- Debian 13（kernel 6.12.95）
- Rocky Linux 9（5.14 系列 kernel）
- Ubuntu 24.04（kernel 6.8.0-134）
修補與緩解
Mainline 修補為 commit 9b2854f86f0b，已回填到以下版本：
6.6.1486.12.1016.18.427.1.67.2-rc5及之後版本
公告給出的 CVSS v4.0 分數為 8.5（High），向量字串為 CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N，符合本機、低權限、免使用者互動即可確定性觸發的特徵。無法立即升級 kernel 的環境，可先透過 seccomp 或 LSM 政策封鎖容器內建立 SCTP socket 作為臨時緩解。此漏洞由騰訊玄武實驗室（Zhuque Lab）研究員 Fourie Zhang 發現並於 2026-08-06 在 oss-security 公開，公告中註明分析過程有借助 AI 輔助驗證。
原始來源：oss-security：CVE-2026-64564: Linux SCTP ASCONF transport UAF
Craft CMS 同日爆兩個免 CVE 卻能遠端執行程式碼的漏洞，另 6 份公告一次看
GitHub Security Advisory · 2026-08-06
Craft CMS 一口氣公布 8 份資安公告，其中兩個是已登入使用者即可達成遠端程式碼執行（RCE）的高風險漏洞：GHSA-f5wm-88jv-g5hx 出在 Twig 沙盒的類別白名單設計，GHSA-265m-7826-wjqm 則出在條件設定（condition）JSON 反序列化時繞過了設定清洗（cleanse）機制。兩者都不需要特殊系統權限，只要攻擊者握有一個能存取控制台（control panel）的帳號即可觸發。
漏洞機制：Twig 沙盒逃逸
Craft 允許有權限的使用者在控制台撰寫 Twig 樣板，為避免樣板執行危險程式碼，Craft 會開啟 Twig 的 SecurityPolicy 沙盒，只放行白名單內的類別與方法。問題是這份白名單是以「整個類別」為單位放行：只要某類別被標記為沙盒內安全（例如透過 AllowedInSandbox attribute），沙盒就會放行它「所有」方法與屬性，包含繼承鏈上父類別的方法。Craft 把內容元素的共同介面 ElementInterface 標成安全，但實作它的 Element 類別最終繼承自 yii\base\Component，而後者內含一段可經由屬性操作串出任意函式呼叫的 gadget。也就是說，白名單只驗證了「這個類別本身可信任」，卻沒有驗證「透過繼承鏈拿到的方法是否同樣安全」，即使網站已呼叫 enableTwigSandbox() 開啟沙盒也擋不住。
漏洞機制：condition.config 清洗繞過
第二個 RCE 走不同路徑。Craft 的搜尋條件功能允許前端把條件設定以 JSON 字串形式送到後端，後端會呼叫 Component::cleanseConfig() 清掉 Yii 保留的特殊設定鍵（例如可掛上行為/事件處理器的 as、on）。但這道清洗只作用在最外層、仍是 JSON 字串狀態的 condition.config 欄位本身；真正把字串解碼、合併進物件設定的 Conditions::createCondition() 卻是在清洗之後才解碼，且未對解碼後內容重新清洗。攻擊者把 as/on 鍵藏在 JSON 字串裡，清洗階段檢查不到字串內部的鍵名，解碼後這些鍵就被 Yii 當成合法的物件設定指令去建立 FieldLayout，執行攻擊者指定的行為邏輯。這條路徑屬於「半盲打」：觸發端點只回傳制式 JSON 回應，需靠伺服器端寫檔案的副作用在後續請求中間接驗證是否得手。
// 概念示意：condition.config 逃過清洗
$outer = ['condition' => ['config' => '{"as behaviors":{"class":"..."}}']];
Component::cleanseConfig($outer); // 只看得到外層字串，看不到內部鍵名
$decoded = json_decode($outer['condition']['config']);
// Conditions::createCondition() 直接用 $decoded 建立 FieldLayout
// 未對 $decoded 重新呼叫 cleanseConfig() → "as"/"on" 被 Yii 當成合法指令受影響版本與修補
| 公告 | 漏洞類型 | CVSS | 受影響版本 | 修補版本 |
|---|---|---|---|---|
GHSA-f5wm-88jv-g5hx | Twig 沙盒逃逸 | 8.7（High） | 4.x：>=4.0.0-RC1 <4.18.3；5.x：>=5.0.0-RC1 <5.10.7 | 4.18.3 / 5.10.7 |
GHSA-265m-7826-wjqm | condition 清洗繞過 | 8.7（High） | 4.x：>=4.0.0-RC1 <4.18.2；5.x：>=5.0.0-RC1 <5.10.5 | 4.18.2 / 5.10.6 |
兩份公告皆未指派 CVE 編號，僅有 GHSA 編號；GitHub 頁面標示的公開日期為 2026-07-25，最後更新為 2026-08-06。升級路徑很單純：4.x 站台升級到對應修補版即可，5.x 站台亦同。
同日公布的其他 6 份公告
Craft 同一天還公布了 6 份風險較低、影響面較窄的公告，這裡不逐一深入，僅列出類型與編號：
- 路徑穿越（path traversal）—
GHSA-7hxc-f267-h5q7 - 環境變數 / 機敏設定外洩 —
GHSA-596p-6jv8-775v - 儲存型 XSS —
GHSA-2rp4-x2j7-qmcc - 密碼重設流程的身分驗證繞過 —
GHSA-p8x7-9vfw-p7vc - 註冊指標（registration metrics）缺少授權檢查 —
GHSA-rvmm-v933-jgxq - Global Sets 重新排序缺少授權檢查 —
GHSA-9p7c-v5x3-rfx8