簡單啲講，就係一個物件被釋放咗兩次（double-put），造成一個經典嘅 use-after-free（UAF） 安全漏洞。攻擊者可以精準操控呢個記憶體釋放嘅時間窗口，篡改核心堆（heap）嘅記憶體配置，最終騎劫宿主機核心嘅控制流程，執行任意程式碼 。

要觸發呢個競爭條件（race condition）完全唔難。惡意 VM 只需要用多個 vCPU 線程，同時發出「DISCARD ITS 指令」同埋「寫入 GITS_CTLR 暫存器」、「清除 redistributor 嘅 EnableLPIs」等操作，就可以喺核心內部製造出競爭條件，引爆呢個漏洞 。

點解咁大件事：ARM64 雲端隔離嘅基石被打破

喺雲端運算嘅世界，Guest-to-Host 逃逸漏洞係最危險嘅漏洞類型，因為佢直接打破咗雲端服務最根本嘅安全假設：一個用戶嘅 VM，絕對冇可能影響到另一個用戶嘅 VM，或者宿主機本身。

以往呢類漏洞多數出現喺 x86 架構嘅 KVM 或者 QEMU 模擬器上面 。ITScape 嘅特別之處，係佢完全繞過咗 QEMU 呢類使用者空間程式，直接攻擊 Linux 核心內部嘅 KVM/arm64 程式碼，係一個純核心級別（in-kernel）嘅漏洞 。

對於所有採用 ARM 伺服器（例如 AWS Graviton、Ampere Altra 等）提供多租戶雲端服務嘅營運商嚟講，惡意 VM 一旦利用呢個漏洞，就可以：

• 任意讀寫宿主機嘅核心記憶體。
• 喺宿主機上以最高權限（ring 0）執行任何程式碼。
• 進一步橫向移動，攻擊同一台宿主機上嘅其他 VM、容器，甚至直接控制宿主機嘅網絡。

絕大多數安全團隊都將呢個漏洞嘅危險評分打到 CVSS 9.0 以上，屬於最高級別嘅「嚴重」（Critical）。

技術細節：競爭條件係點樣產生？

問題出喺 vgic_its_invalidate_cache() 呢個函式。當核心需要清空 LPI 翻譯快取嗰陣，佢會用 xa_for_each() 呢個迭代器去拜訪 XArray 數據結構入面嘅所有條目，然後為每個拜訪到嘅條目呼叫一次 vgic_put_irq() 去釋放參考。

但最關鍵嘅 Bug 係：xa_for_each() 迭代器會返回所有佢撞到嘅條目指標，包括嗰啲喺並行操作入面已經被 xa_erase() 成功移除嘅條目。由於失效函式唔識得分辨呢個情況，佢會對住一個已經被移除（甚至記憶體已經被回收再利用）嘅物件再次進行釋放，造成 double-put，最終導致 use-after-free 。

有趣嘅係，同一個子系統早喺 CVE-2024-26598 嘅時候就修補過一個類似嘅 UAF 漏洞，當時係發生喺翻譯快取嘅「查詢（hit）」路徑上。嗰次嘅修補方案係喺 vgic_its_check_cache() 函式入面，先增加物件嘅參考計數（refcount），確保鎖定解除之後物件唔會被意外釋放。可惜呢個修補冇覆蓋到今次出事嘅「失效（invalidate）」路徑，令到攻擊者有另一條路可以觸發漏洞 。

修補方案

上游（upstream）Linux 核心開發團隊已經迅速作出反應，修補咗呢個漏洞。修補嘅方法好直接：修改 vgic_its_invalidate_cache() 函式嘅邏輯，令佢只係為 xa_erase() 函式成功移除並返回嘅嗰個特定條目去呼叫 vgic_put_irq() 釋放參考。

xa_erase() 呢個函式係原子操作，佢會嘗試移除一個條目，如果成功就返回舊嘅條目指標；如果條目已經唔存在，佢就會返回 NULL。透過檢查 xa_erase() 嘅返回值，就可以確保每個物件嘅參考只會被釋放恰好一次，徹底杜絕 double-put 嘅風險 。

呢個關鍵修補喺 2026 年 6 月初被合併到 Linux 核心主線，並喺隨後幾日內被快速反向移植（backport）到各個 6.x 穩定版本核心。Red Hat、SUSE、Debian 等主要發行版，亦都已經針對佢哋支援嘅核心版本發布咗安全更新 。

影響範圍同版本

• 漏洞引入時間： 大約 2024 年 4 月底。當時 LPI 翻譯快取功能首次被加入到 KVM/arm64 程式碼入面 。
• 受影響版本： 由 2024 年 4 月底至 2026 年 6 月初之間構建嘅所有上游 Linux 核心版本 。
• 已修補版本： 喺 2026 年 6 月初發布嘅上游修補程式，已被包含喺最新嘅 6.x 穩定版核心，以及各大發行版嘅安全更新入面 。

概念驗證攻擊碼（PoC）已公開

研究員 Hyunwoo Kim 喺公開漏洞細節嘅同時，亦喺 GitHub 上發布咗一個完整可用嘅概念驗證攻擊程式 。呢個 Repository 入面包含咗完整嘅原始碼、詳盡嘅重現步驟，同埋對漏洞利用技巧嘅技術描述。

個 PoC 透過協調多個 vCPU 線程，同時執行 DISCARD 指令同翻譯快取查詢，精準咁觸發競爭條件，最尾成功實現 use-after-free 同埋宿主機程式碼執行。公開可用嘅可靠 PoC 意味住，黑客同自動化攻擊掃描器幾乎可以「零成本」武器化呢個漏洞，由漏洞公開到被大規模利用嘅時間差距將會非常之短 。

營運商緊急緩解措施

如果你負責營運多租戶嘅 ARM64 KVM 基礎設施（例如 AWS Graviton、Ampere Altra 或任何類似平台），請將今次事件視為最高級別嘅緊急事故，需要立即採取行動。

1. 即刻為宿主機核心打補丁。 安裝包含 2026 年 6 月初修補程式嘅最新穩定版核心，或者你使用嘅 Linux 發行版所提供嘅反向移植安全更新包 。
2. 如果暫時冇辦法修補，就要即刻為所有唔信任嘅 VM 停用核心內建嘅 vGIC-ITS 功能。 喺 QEMU 嘅設定入面，可以透過強制將 GICv3 ITS 嘅模擬工作交返畀使用者空間（userspace），或者唔向唔信任嘅租戶 VM 暴露 GICv3 ITS 嘅功能嚟實現 。
3. 唔好依賴任何 VM 內部嘅防護措施。 呢個係一個存在於虛擬機管理器（hypervisor）級別嘅錯誤，VM 內部冇任何有效嘅緩解方法 。
4. 審計你嘅伺服器機隊。 確認所有行緊 KVM/arm64 嘅宿主機核心版本，係咪喺漏洞影響範圍內（2024 年 4 月至 2026 年 6 月），而且係咪有啟用 vGIC-ITS 功能 。
5. 監察系統有冇被入侵嘅跡象。 由於 PoC 攻擊碼已經公開，現時好大機會已經有黑客喺度進行大規模掃描同攻擊嘗試 。

簡單啲講，就係一個物件被釋放咗兩次（double-put），造成一個經典嘅 use-after-free（UAF） 安全漏洞。攻擊者可以精準操控呢個記憶體釋放嘅時間窗口，篡改核心堆（heap）嘅記憶體配置，最終騎劫宿主機核心嘅控制流程，執行任意程式碼 。

要觸發呢個競爭條件（race condition）完全唔難。惡意 VM 只需要用多個 vCPU 線程，同時發出「DISCARD ITS 指令」同埋「寫入 GITS_CTLR 暫存器」、「清除 redistributor 嘅 EnableLPIs」等操作，就可以喺核心內部製造出競爭條件，引爆呢個漏洞 。

點解咁大件事：ARM64 雲端隔離嘅基石被打破

喺雲端運算嘅世界，Guest-to-Host 逃逸漏洞係最危險嘅漏洞類型，因為佢直接打破咗雲端服務最根本嘅安全假設：一個用戶嘅 VM，絕對冇可能影響到另一個用戶嘅 VM，或者宿主機本身。

以往呢類漏洞多數出現喺 x86 架構嘅 KVM 或者 QEMU 模擬器上面 。ITScape 嘅特別之處，係佢完全繞過咗 QEMU 呢類使用者空間程式，直接攻擊 Linux 核心內部嘅 KVM/arm64 程式碼，係一個純核心級別（in-kernel）嘅漏洞 。

對於所有採用 ARM 伺服器（例如 AWS Graviton、Ampere Altra 等）提供多租戶雲端服務嘅營運商嚟講，惡意 VM 一旦利用呢個漏洞，就可以：

• 任意讀寫宿主機嘅核心記憶體。
• 喺宿主機上以最高權限（ring 0）執行任何程式碼。
• 進一步橫向移動，攻擊同一台宿主機上嘅其他 VM、容器，甚至直接控制宿主機嘅網絡。

絕大多數安全團隊都將呢個漏洞嘅危險評分打到 CVSS 9.0 以上，屬於最高級別嘅「嚴重」（Critical）。

技術細節：競爭條件係點樣產生？

問題出喺 vgic_its_invalidate_cache() 呢個函式。當核心需要清空 LPI 翻譯快取嗰陣，佢會用 xa_for_each() 呢個迭代器去拜訪 XArray 數據結構入面嘅所有條目，然後為每個拜訪到嘅條目呼叫一次 vgic_put_irq() 去釋放參考。

但最關鍵嘅 Bug 係：xa_for_each() 迭代器會返回所有佢撞到嘅條目指標，包括嗰啲喺並行操作入面已經被 xa_erase() 成功移除嘅條目。由於失效函式唔識得分辨呢個情況，佢會對住一個已經被移除（甚至記憶體已經被回收再利用）嘅物件再次進行釋放，造成 double-put，最終導致 use-after-free 。

有趣嘅係，同一個子系統早喺 CVE-2024-26598 嘅時候就修補過一個類似嘅 UAF 漏洞，當時係發生喺翻譯快取嘅「查詢（hit）」路徑上。嗰次嘅修補方案係喺 vgic_its_check_cache() 函式入面，先增加物件嘅參考計數（refcount），確保鎖定解除之後物件唔會被意外釋放。可惜呢個修補冇覆蓋到今次出事嘅「失效（invalidate）」路徑，令到攻擊者有另一條路可以觸發漏洞 。

修補方案

上游（upstream）Linux 核心開發團隊已經迅速作出反應，修補咗呢個漏洞。修補嘅方法好直接：修改 vgic_its_invalidate_cache() 函式嘅邏輯，令佢只係為 xa_erase() 函式成功移除並返回嘅嗰個特定條目去呼叫 vgic_put_irq() 釋放參考。

xa_erase() 呢個函式係原子操作，佢會嘗試移除一個條目，如果成功就返回舊嘅條目指標；如果條目已經唔存在，佢就會返回 NULL。透過檢查 xa_erase() 嘅返回值，就可以確保每個物件嘅參考只會被釋放恰好一次，徹底杜絕 double-put 嘅風險 。

呢個關鍵修補喺 2026 年 6 月初被合併到 Linux 核心主線，並喺隨後幾日內被快速反向移植（backport）到各個 6.x 穩定版本核心。Red Hat、SUSE、Debian 等主要發行版，亦都已經針對佢哋支援嘅核心版本發布咗安全更新 。

影響範圍同版本

• 漏洞引入時間： 大約 2024 年 4 月底。當時 LPI 翻譯快取功能首次被加入到 KVM/arm64 程式碼入面 。
• 受影響版本： 由 2024 年 4 月底至 2026 年 6 月初之間構建嘅所有上游 Linux 核心版本 。
• 已修補版本： 喺 2026 年 6 月初發布嘅上游修補程式，已被包含喺最新嘅 6.x 穩定版核心，以及各大發行版嘅安全更新入面 。

概念驗證攻擊碼（PoC）已公開

研究員 Hyunwoo Kim 喺公開漏洞細節嘅同時，亦喺 GitHub 上發布咗一個完整可用嘅概念驗證攻擊程式 。呢個 Repository 入面包含咗完整嘅原始碼、詳盡嘅重現步驟，同埋對漏洞利用技巧嘅技術描述。

個 PoC 透過協調多個 vCPU 線程，同時執行 DISCARD 指令同翻譯快取查詢，精準咁觸發競爭條件，最尾成功實現 use-after-free 同埋宿主機程式碼執行。公開可用嘅可靠 PoC 意味住，黑客同自動化攻擊掃描器幾乎可以「零成本」武器化呢個漏洞，由漏洞公開到被大規模利用嘅時間差距將會非常之短 。

營運商緊急緩解措施

如果你負責營運多租戶嘅 ARM64 KVM 基礎設施（例如 AWS Graviton、Ampere Altra 或任何類似平台），請將今次事件視為最高級別嘅緊急事故，需要立即採取行動。

1. 即刻為宿主機核心打補丁。 安裝包含 2026 年 6 月初修補程式嘅最新穩定版核心，或者你使用嘅 Linux 發行版所提供嘅反向移植安全更新包 。
2. 如果暫時冇辦法修補，就要即刻為所有唔信任嘅 VM 停用核心內建嘅 vGIC-ITS 功能。 喺 QEMU 嘅設定入面，可以透過強制將 GICv3 ITS 嘅模擬工作交返畀使用者空間（userspace），或者唔向唔信任嘅租戶 VM 暴露 GICv3 ITS 嘅功能嚟實現 。
3. 唔好依賴任何 VM 內部嘅防護措施。 呢個係一個存在於虛擬機管理器（hypervisor）級別嘅錯誤，VM 內部冇任何有效嘅緩解方法 。
4. 審計你嘅伺服器機隊。 確認所有行緊 KVM/arm64 嘅宿主機核心版本，係咪喺漏洞影響範圍內（2024 年 4 月至 2026 年 6 月），而且係咪有啟用 vGIC-ITS 功能 。
5. 監察系統有冇被入侵嘅跡象。 由於 PoC 攻擊碼已經公開，現時好大機會已經有黑客喺度進行大規模掃描同攻擊嘗試 。