Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - KVM：x86：修正由於意外的 GFN 而導致的陰影分頁釋放後使用 影子 MMU 使用 sp->gfn 加上 SPTE 索引計算直接影子頁面的 GFN。如果在虛擬機器項目之間修改客體頁面表格，則此假設會中斷影子分頁 （類似於提交 aad885e77496，KVM：x86/mmu：即使建立 MMIO SPTE 時，也會刪除/zap 現有的現有 SPTE，2026-03-27）。流程如下： - 針對 2MB 對映安裝偏微分方程，並存取該區域中的頁面。KVM 建立一個由 512 個 4KB 頁面組成的kvm_mmu_page;kvm_mmu_page被 FNAME（fetch） 標記為直接映射，因為客體的映射是一個巨大的頁面（因此是連續的）。- PDE 對映會從客體外部變更。- 訪客存取相同 2MB 區域中的另一個頁面。KVM 會安裝新的葉子 SPTE 和 rmap 項目;SPTE 使用正確的 GFN （即基於新映射，如上一步中所更改），但該 GFN 超出 [sp->gfn， sp->gfn + 511] 範圍;因此，當 zapped 時，無法找到並移除 rmap 項目kvm_mmu_page。- 覆蓋前 2MB 映射的內插槽被刪除，並且現在無效的 GPA 的kvm_mmu_page被刪除。但是，rmap_remove（） 只會查看步驟 1 中建立的 [sp->gfn， sp->gfn + 511] 範圍，找不到步驟 3 所記錄的 rmap 項目。- 針對步驟 3 所存取之相同頁面造成 rmap 遍歷的任何作業，然後遍歷過時的 rmap 並取消參照已釋放的kvm_mmu_page。這包括髒記錄或 MMU 通知程式無效 （例如，來自 MADV_DONTNEED）。根本問題是，KVM 的影子 PTE 行走假設，如果 KVM 想要安裝非葉 SPTE 時存在 SPTE，則現有kvm_mmu_page必須用於正確的 gfn。因為 gfn 出錯的唯一方法是 KVM 搞砸並且無法電擊 SPTE...這不應該發生，但是
    *實際上* 只會在回應來賓寫信時發生。這個錯誤實際上可以追溯到永遠，因為即使是 KVM 的第一個版本也假設 GFN 匹配並進入錯誤的影子頁面。然而，這只是一個不精確性，直到 2032a93d66fa（KVM：MMU：不要為直接 mmu 頁面分配 gfns 頁面）出現。透過檢查目標 gfn 不相符並刪除現有 SPTE 來修正它。這樣舊的 SP 和 rmap 條目就消失了，KVM 將 rmap 安裝在正確的位置，每個人都很高興。
    (CVE-2026-46113)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補弱點：CVE-2026-46113

high Nessus Plugin ID 317633

版本 1.30