遠端 OracleVM 系統缺少可解決安全性更新的必要修補程式：

  - 在 Xen 4.14.x 及之前版本中發現一個問題。PCI passthrough 程式碼未正確使用暫存器資料。
    在 Xen 的 MSI 處理中發現程式碼路徑，其會作用於從裝置硬體暫存器回讀的未清理值。雖然嚴格符合 PCI 規格的裝置應不能影響這些暫存器，但經驗顯示，裝置通常會發生超出規格的「後門」作業，進而影響這些讀取的結果。未完全受信任的來賓可能會損毀 Xen，進而導致整個系統拒絕服務 (DoS)。無法排除權限提升和資訊洩漏。所有支援 PCI passthrough 的 Xen 版本都會受到影響。僅 x86 系統會受到影響。Arm 系統不受影響。只有成功傳遞 PCI 裝置的來賓才能利用此弱點。只有經過具有超規格 (後門) 功能的裝置傳遞的系統才會造成問題。經驗顯示，這種超出規格的功能很常見。除非您有理由相信您的裝置不具備此類功能，否則最好假設其具有此類功能。(CVE-2020-25595)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。未正確處理「已經有效的事件通道可能不會變為無效」這一限制條件。Xen 中事件通道作業的處理邏輯假設事件通道一旦有效，就不會在來賓的生命週期內變為無效。但是，在確定有效性時，諸如重設所有事件通道之類的操作可能會減少其中某一檢查邊界。這可能會導致觸發錯誤檢查，進而損毀主機。無權限的客體可能會損毀 Xen，進而導致整個系統拒絕服務。Xen 4.4 及之後所有版本都容易受到影響。Xen 4.3 及更早版本不會受到影響。只有允許不受信任來賓機建立超過預設數量之事件通道的系統，才易受攻擊。此數字取決於來賓機的架構和類型。對於 32 位元 x86 PV 來賓機，此數字為 1023；對於 64 位元 x86 PV 來賓機以及所有 ARM 來賓機，此數字為 4095。限制不受信任來賓機建立少於此數目之事件通道的系統不會受到影響。請注意，xl 和 libxl 預設將 max_event_channels 限制為 1023，因此專門使用 xl、libvirt+libxl 或其自己的以 libxl 為基礎的 toolstack 且未明確設定 max_event_channels 的系統不會受到影響。(CVE-2020-25597)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。存在 evtchn_reset() 爭用情形。使用 EVTCHNOP_reset (可能由來賓機本身) 或 XEN_DOMCTL_soft_reset (由 XSA-77 涵蓋) 可導致違反多種內部假設。這可能會導致超出邊界記憶體存取或觸發錯誤檢查。特別是，x86 PV 來賓機可能能夠將其權限提升至主機權限。另外，也有可能發生主機和來賓機當機，進而導致拒絕服務 (DoS)。無法排除資訊洩漏狀況。Xen 4.5 及之後所有版本都容易受到影響。Xen 4.4 及更早版本不會受到影響。(CVE-2020-25599)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。超出邊界事件通道可用於 32 位元 x86 網域。所謂的 2 層事件通道模型會對 32 位元 x86 網域和 64 位元或 Arm (任一個位元組) 網域可用的事件通道數量施加不同限制。 32 位元 x86 網域只能使用 1023 個通道，這是因為其共用 (來賓和 Xen 之間) 資訊結構中的空間有限所致，而在此模型中，所有其他網域最多可使用 4095 個通道。但是，在網域初始化期間，在實際接受個別網域內容之前，只要網域仍然被視為 64 位元網域，程式就已經記錄了個別限制。在將網域識別為 32 位元的情況下，並未相應更新限制。由於 Xen 中的這一錯誤行為，為其他網域提供服務的 32 位元網域 (包括網域 0) 可能會觀察到事件通道配置在實際應該失敗時成功。
    後續使用此類事件通道可能會導致共用資訊結構的其他部分損毀。無權限的來賓可造成其他網域 (尤其是網域 0) 運作不當。這可導致整個系統發生拒絕服務 (DoS)。Xen 4.4 及之後所有版本都容易受到影響。Xen 4.3 版和更早版本不會受到影響。只有服務其他網域的 x86 32 位元網域容易受到影響。Arm 系統以及 x86 64 位元網域不受此弱點影響。(CVE-2020-25600)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。evtchn_reset() / evtchn_destroy() 中缺少先佔安排。特別是，FIFO 事件通道模型允許來賓機一次建立大量事件通道。(在重設所有事件通道或在來賓機建立後清理時) 關閉所有這些項目，可能會花費更長的時間。到目前為止，尚無適當間隔的先佔安排，導致 CPU 在處理這些作業時花費幾乎無限的時間。惡意或錯誤來賓核心可掛載影響整個系統的拒絕服務 (DoS) 攻擊。原則上，所有 Xen 版本都容易受到影響。Xen 4.3 版和更舊版本是否容易受到影響，取決於基礎硬體特性。(CVE-2020-25601)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。存取/配置事件通道時缺少記憶體障礙。只要認為連接埠有效，就可以無鎖定存取事件通道控制結構。此類序列缺少適當的記憶體障礙 (例如 smp_*mb())，以防止編譯器和 CPU 重新排序存取。惡意來賓機可造成 Xen 當機，進而導致拒絕服務 (DoS)。無法排除資訊洩漏和權限提升狀況。執行所有 Xen 版本的系統皆會受到影響。系統是否易受攻擊取決於構建 Xen 所使用的 CPU 和編譯器。在所有系統中，此弱點的存在與影響範圍取決於用來構建 Xen 的編譯器所執行的精確重新排序。我們無法調查編譯器，因此無法說出哪些編譯器（使用哪些程式碼產生選項）可能產生有弱點的程式碼。GCC 文件明確指出可以重新排序。如果 CPU 能夠重新排序記憶體存取，Arm 系統也將容易受到影響。請諮詢您的 CPU 供應商。x86 系統只有在編譯器執行重新排序時才會受到影響。(CVE-2020-25603)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。在 x86 HVM vCPU 之間移轉計時器時發生爭用情形。在 x86 HVM 來賓機的 vCPU 之間移轉計時器時，所用的鎖定模型會允許相同來賓機的第二個 vCPU 在計時器上運作，以釋放其未取得的鎖定。此問題最可能造成的影響是 Hypervisor 懸置或損毀，即拒絕服務 (DoS)。所有 Xen 版本皆會受到影響。僅 x86 系統會受到影響。Arm 系統不受影響。只有 x86 HVM 來賓機可利用此弱點。x86 PV 和 PVH 無法利用此弱點。只有具有多個 vCPU 的來賓機才能惡意利用此弱點。(CVE-2020-25604)

  - 在 Xen 4.14.x 及更早版本中發現一個問題，其允許 x86 HVM 和 PVH 來賓機 OS 使用者透過不當合併每頁 IOMMU TLB 刷新，造成拒絕服務 (資料損毀)、資料洩漏或可能取得權限。(CVE-2020-27671)

  - 在 Xen 4.14.x 機更早版本中發現一個問題，其允許 x86 來賓機 OS 使用者惡意利用爭用情形導致 2MiB 和 1GiB 超級頁面出現釋放後使用問題，從而造成主機 OS 拒絕服務、損毀資料或可能取得權限。(CVE-2020-27672)

  - Xen 4.14.x 及更早版本允許來賓機 OS 管理員透過電源/能源監控介面上的側通道攻擊 (即 Platypus 攻擊) 取得敏感資訊 (例如，來自來賓機外部的 AES 金鑰)。注意：只有一個邏輯上獨立的修正：變更 Xen 中每個此類介面的存取控制。(CVE-2020-28368)

  - 在 Xen 4.14.x 及更早版本中發現一個問題，其允許 x86 HVM 來賓機 OS 使用者透過差一錯誤，造成拒絕服務 (資料損毀)、資料洩漏或可能取得權限。注意：
    此問題是因為不完整修正 CVE-2020-27671 所致。(CVE-2020-29040)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。報告 xenstore 監視事件時，所有 xenstore 實作皆不會執行任何權限檢查。來賓系統管理員可監視 root xenstored 節點，這會造成每次建立、修改和刪除金鑰時都會發出通知。來賓系統管理員也可使用特殊監視，這會造成每次建立及損毀網域時都會發出通知。資料可能包括：其他 VM 的數量、類型和 Domid；驅動程式網域的存在與 Domid；虛擬介面的數量、區塊裝置、vcpus；虛擬框架緩衝區及其後端樣式的存在 (例如 VNC 服務的存在)；其他網域的 Xen VM UUID；網域建立和裝置設定的定時資訊；以及 VM 及其裝置後端佈建的一些提示。監視事件不包含儲存在 xenstore 中的值，僅包含金鑰名稱。來賓系統管理員可觀察與其他來賓相關的非敏感網域和裝置生命週期事件。透過此資訊，可以在一定程度上瞭解整體系統組態 (包括其他客體的數量和一般特性)，以及其他客體的組態 (包括其他客體裝置的數量和一般特性)。此資訊可能具有商業用途，也可能使其他攻擊更容易發生。據信不存在敏感資料洩漏問題。具體而言，不會洩漏 VNC 密碼、連接埠號碼、主機和來賓機檔案系統中的路徑名稱、密碼編譯金鑰或來賓機內資料。(CVE-2020-29480)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。Xenstore 節點的存取權是依 domid 而定。
    遺憾的是，當網域遭到破壞時，並未移除現有授予的存取權。這表示以相同 domid 建立的新網域將從具有相同 domid 的先前網域繼承 Xenstore 節點的存取權。由於來賓機遭到破壞時，Xen 工具會刪除 /local/domain/<domid> 下來賓機的所有 Xenstore 項目，因此只有仍在執行中的其他來賓機的 Xenstore 項目會受到影響。例如，新建立的來賓機網域可能會讀取屬於先前存在的來賓機網域的敏感資訊。兩個 Xenstore 實作 (C 和 Ocaml) 都有弱點。(CVE-2020-29481)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。Xenstored 和客體透過使用特定通訊協定的共用記憶體頁面進行通訊。當客體違反此通訊協定時，xenstored 會中斷該客體的連線。但遺憾的是，這是透過從 xenstored 的內部管理中移除客體來完成的，這會導致與客體遭到破壞時相同的動作，包括傳送 @releaseDomain 事件。 @releaseDomain 事件不會指出客體已遭移除。此事件的所有監控程式都必須查看所有客體的狀態，才能找到已移除的客體。當因網域 xenstored 通訊協定違規行為而產生 @releaseDomain 時，因為客體仍在執行中，所以監控程式不會做出反應。之後，當客體實際遭到破壞時，xenstored 不會再將其儲存在內部資料庫中，因此不會再傳送進一步的 @releaseDomain 事件。這可能會導致殭屍網域；
    由於遺漏事件，系統不會移除該來賓機記憶體的記憶體對應。只會在另一個網域遭到損毀後再清除此殭屍網域，這是因為此操作會觸發另一個 @releaseDomain 事件。如果違反 Xenstore 通訊協定的客體裝置模型在 stub 網域中執行，從內部資料庫中移除此客體後，xenstored 中可能會發生釋放後使用情形，進而可能導致 xenstored 損毀。惡意客體可在自身終止後的一段時間內封鎖主機的資源。具有 stub 網域裝置模型的客體最終可造成 xenstored 損毀，進而導致更嚴重的拒絕服務 (阻止任何進一步的網域管理作業)。只有 Xenstore 的 C 變體受到影響； Ocaml 變體不受影響。只有具有 stubdom 裝置模型的 HVM 來賓機才能造成嚴重的 DoS。(CVE-2020-29483)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。當 Xenstore 監視觸發時，註冊監看的 xenstore 用戶端將收到一則 Xenstore 訊息，其中包含觸發監視的已修改 Xenstore 項目路徑，以及註冊監視時指定的標籤。與 xenstored 的任何通訊皆透過 Xenstore 訊息完成，其中包含訊息標頭和有效承載。承載長度限制為 4096 個位元組。任何導致回應承載長度超過 4096 位元組的 xenstored 要求都會造成錯誤。註冊監視時，承載長度限制適用於監看路徑和指定標籤的組合長度。由於特定路徑的監視也會針對該路徑之下的所有節點觸發，因此監視事件訊息的承載可能比註冊監視所需的承載更長。使用非常大的標籤 (即註冊作業承載長度接近 4096 位元組) 註冊監視的惡意來賓機，可透過於監視路徑下方寫入 Xenstore 項目，造成產生承載長度大於 4096 位元組的監視事件。這將導致 xenstored 中發生錯誤情形。此錯誤可導致 NULL 指標解除參照，進而造成 xenstored 損毀。惡意來賓機系統管理員可造成 xenstored 當機，進而導致拒絕服務。在 xenstored 損毀之後，網域可能會繼續執行，但無法進行管理作業。只有 C xenstored 受到影響，oxenstored 不受影響。
    (CVE-2020-29484)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。由 Xen 維護的 per-vCPU 控制區塊對應記錄和指標對應控制區塊的記錄相反。使用者在看到前者已初始化的情況下假設後者也已準備就緒，可供使用。惡意或錯誤來賓機核心可發起影響整個系統的拒絕服務 (DoS) 攻擊。(CVE-2020-29570)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Xen 伺服器的 FIFO 事件通道模組 evtchn_reset() / evtchn_destroy() 中存在一個拒絕服務 (DoS) 弱點，這是因為缺少先佔所導致。經驗證的本機攻擊者可掛載影響整個系統的拒絕服務 (DoS) 攻擊。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼。

遠端 Ubuntu 20.04 LTS 主機上安裝的套件受到 USN-5617-1 公告中所提及的多個弱點影響。

  - 在某些 Intel(R) 處理器中，特定的特殊暫存器讀取作業若清理不完全，經驗證的使用者則可能透過本機存取造成資訊洩漏。(CVE-2020-0543)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於讀寫解鎖路徑中缺少記憶體屏障，來賓作業系統使用者可利用此問題造成拒絕服務，或可能取得權限。讀寫解鎖路徑未包含記憶體屏障。在 Arm 上，這表示系統允許處理器按照前面的操作針對記憶體存取進行重新排序。換句話說，在存取關鍵區段內的所有記憶體之前，另一個處理器可能會看到解除鎖定。因此，可能會讓寫入器與讀取器或其他寫入器同時執行關鍵區段。換句話說，關鍵區段中的許多假設 (例如，檢查後無法修改變數) 不再安全。讀寫鎖定用於 Hypercall (例如 grant-table 呼叫)，因此惡意來賓可利用此爭用情形。例如，如果同時使用 XENMAPSPACE_grant_table，則存在 Xen 洩漏記憶體的短時窗口。惡意來賓機可造成記憶體洩漏，或造成 Hypervisor 損毀，進而導致拒絕服務 (DoS)。不排除資訊洩漏和權限提升狀況。(CVE-2020-11739)

  - 在 Xen 4.13.x 以及之前所有版本的 xenoprof 中發現一個問題，此問題允許客體作業系統使用者 (無主動式分析) 取得有關其他客體的敏感資訊。無權限的來賓可要求對應 xenoprof 緩衝區，即使尚未針對這些來賓啟用分析也是如此。未清除這些緩衝區。(CVE-2020-11740)

  - 在 Xen 4.13.x 以及之前所有版本的 xenoprof 中發現一個問題，此問題允許客體作業系統使用者 (有主動式分析) 取得有關其他客體的敏感資訊，從而造成拒絕服務或可能取得特權。對於系統管理員已啟用主動式分析的來賓，xenoprof 程式碼會使用標準的 Xen 共用環結構。但遺憾的是，這段程式碼並未將來賓視為潛在的攻擊者：它信任來賓不會以非預期的方式修改緩衝區大小資訊或修改標頭/結尾指標。這可造成主機當機 (DoS)。不排除權限提升狀況。
    (CVE-2020-11741)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於 GNTTABOP_copy 中未正確執行連續處理，客體作業系統使用者可利用此問題造成拒絕服務。授權表格作業預期成功時會傳回 0，錯誤則傳回負數。CVE-2017-12135 的修復透過授權複製處理引入了一個路徑，可能會在未採取任何動作的情況下向呼叫者傳回成功訊息。具體而言，個別作業的狀態欄位會保持未初始化狀態，且可能導致 GNTTABOP_copy 的呼叫者出現錯誤行為。錯誤或惡意的客體可建構其授權表，使當後端網域嘗試複製授權時，其會碰到不正確的錯誤路徑。這會在沒有任何動作的情況下向呼叫者傳回成功訊息，進而可能造成系統當機或其他錯誤行為。(CVE-2020-11742)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於 GNTTABOP_map_grant 中存在不良錯誤路徑，客體作業系統使用者可利用此問題造成拒絕服務。授權表格作業預期成功時會傳回 0，錯誤則傳回負數。某些位置不正確的括號會造成一個錯誤路徑傳回 1，而非傳回負值。Linux 中的授權表程式碼將此情況視為成功，並繼續以錯誤的初始化狀態進行。錯誤或惡意的客體可建構其授權表，使當後端網域嘗試對應授權時，其會碰到不正確的錯誤路徑。這會損毀 Linux 型 dom0 或後端網域。(CVE-2020-11743)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，此問題允許 x86 HVM 客體作業系統使用者造成 Hypervisor 損毀。x86 HVM 客體的惡意視訊 RAM 追踪程式碼中存在一個反轉條件，其允許此類客體將 Xen 解除參照保證指向未對應空間的指標。惡意或錯誤的 PV 客體可能會造成 Hypervisor 當機，進而導致影響到整個主機的拒絕服務 (DoS) 情形。Xen 4.8 之後版本會受到影響。Xen 4.7 版和更早版本不會受到影響。僅 x86 系統受到影響。
    Arm 系統不受影響。只有使用陰影分頁的 x86 HVM 客體可利用此弱點。此外，實體必須主動監控客體的視訊框架緩衝區 (通常用於顯示用途)，以便這類客體能夠利用此弱點。x86 PV 客體以及使用硬體協助分頁 (HAP) 的 x86 HVM 客體無法利用此弱點。
    (CVE-2020-15563)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於 VCPUOP_register_vcpu_info 中缺少對齊檢查，Arm 客體作業系統使用者可利用此問題造成 Hypervisor 損毀。客體使用 Hypercall VCPUOP_register_vcpu_info 在 Hypervisor 中註冊共用區域。該區域將會對應至 Xen 位址空間，因此可以直接存取。在 Arm 上，要使用需要特殊對齊的指示來存取此區域。但遺憾的是，系統無法檢查客體所提供的位址是否會正確對齊。因此，惡意客體可透過傳遞不相符的位址，造成 Hypervisor 損毀。惡意客體系統管理員可造成 Xen 當機，進而導致拒絕服務 (DoS)。所有 Xen 版本都容易受到影響。只有 Arm 系統會受到影響。x86 系統不受影響。(CVE-2020-15564)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於 VT-d 下的快取回寫不充分，x86 Intel HVM 客體作業系統使用者可利用此問題造成主機作業系統拒絕服務，或可能取得權限。當 IOMMU 和 CPU 共用分頁表時，變更分頁表需要同時排清兩個 TLB。此外，IOMMU 可能非連貫，因此在排清 IOMMU TLB 之前，CPU 快取也需要在進行變更之後回寫至記憶體。尤其是在將大型頁面對應分割為較小粒度的頁面對應時，會遺漏這種快取資料的回寫。惡意來賓可能會保留對傳回至 Xen 可用集區之框架的讀取/寫入 DMA 存取權，並在之後將其重複用於其他用途。不排除主機當機 (導致拒絕服務) 和權限提升的情況。至少 Xen 3.2 之後版本會受到影響。只有 x86 Intel 系統受到影響。 x86 AMD 和 Arm 系統不受影響。只有使用硬體協助分頁 (HAP)、已指派傳遞 PCI 裝置並啟用分頁表共用的 x86 HVM 來賓可利用此弱點。請注意，只有在 Xen 認為 IOMMU 和 CPU 大頁面支援相容時，才會啟用分頁表共用 (預設狀態下)。(CVE-2020-15565)

  - 在 Xen 4.13.x 及之前的所有版本中發現一個問題，由於事件通道連接埠配置中的錯誤處理不正確，客體 OS 使用者可利用此問題造成主機作業系統損毀。事件通道連接埠的配置可能因多種原因而失敗：(1) 連接埠已在使用中，(2) 記憶體配置失敗，或 (3) 我們嘗試配置的連接埠高於來賓使用的 ABI (例如 2L 或 FIFO) 支援的連接埠數量或系統管理員設定的限制 (xl cfg 中的 max_event_channels)。由於缺少錯誤檢查，因此只有第 (1) 中情形會被視為錯誤。在所有其他情況下都將提供有效的連接埠，並在嘗試存取事件通道時導致當機。系統管理員將客體設定為允許超過 1023 個事件通道時，該客體可能會造成主機當機。當 Xen 記憶體不足時，配置新事件通道將導致主機當機，而非報告錯誤。Xen 4.10 版和更高版本不會受到影響。所有架構都會受到影響。使用 xl/libxl 建立來賓時，預設組態不受預設事件通道限制影響。(CVE-2020-15566)

  - 在 Xen 4.13.x 以及之前的所有版本中發現一個問題，由於即時 EPT PTE 的非原子修改，Intel 客體作業系統使用者可利用此問題取得權限或造成拒絕服務。對應客體 EPT (巢狀分頁) 表格時，Xen 在某些情況下會使用一系列非原子的 bitfield 寫入。視編譯器版本和最佳化旗標而定，Xen 可能會將部分寫入的危險 PTE 洩漏給硬體，讓攻擊者得以爭相惡意利用。來賓系統管理員甚或無權限的來賓使用者可能會造成拒絕服務、資料損毀或權限提升。僅使用 Intel CPU 的系統會受影響。使用 AMD CPU 的系統和 Arm 系統不受影響。只有使用巢狀分頁 (hap，即巢狀分頁，在此情況下為 Intel EPT) 的系統容易受到影響。僅 HVM 和 PVH 客體可利用此弱點。此弱點的存在與範圍取決於用來構建 Xen 的編譯器所執行的精確最佳化。如果編譯器產生 (a) 單一 64 位元寫入，或 (b) 一系列與原始程式碼相同順序的 read-modify-write 作業，則 Hypervisor 不會受到影響。例如，在一個使用 GCC 8.3 且具有正常設定的測試版本中，編譯器會以原始程式碼順序產生多個 (未鎖定的) read-modify-write 作業，這並不構成弱點。我們無法調查編譯器，
    因此無法判斷哪些編譯器（使用哪些程式碼產生選項）可能產生有弱點的程式碼。原始程式碼明顯違反 C 規則，因此應將其視為存在弱點。
    (CVE-2020-15567)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。PCI passthrough 程式碼未正確使用暫存器資料。
    在 Xen 的 MSI 處理中發現程式碼路徑，其會作用於從裝置硬體暫存器回讀的未清理值。雖然嚴格符合 PCI 規格的裝置應不能影響這些暫存器，但經驗顯示，裝置通常會發生超出規格的「後門」作業，進而影響這些讀取的結果。未完全受信任的來賓可能會損毀 Xen，進而導致整個系統拒絕服務 (DoS)。無法排除權限提升和資訊洩漏。所有支援 PCI passthrough 的 Xen 版本都會受到影響。僅 x86 系統會受到影響。Arm 系統不受影響。只有成功傳遞 PCI 裝置的來賓才能利用此弱點。只有經過具有超規格 (後門) 功能的裝置傳遞的系統才會造成問題。經驗顯示，這種超出規格的功能很常見。除非您有理由相信您的裝置不具備此類功能，否則最好假設其具有此類功能。(CVE-2020-25595)

  - 在 Xen 4.14.x 以及之前的所有版本中發現一個問題。 x86 PV 來賓核心可能遭到透過 SYSENTER 執行的拒絕服務攻擊。SYSENTER 指令會將各種狀態清理活動留給軟體。Xen 的一個清理路徑插入了 #GP 錯誤，並會錯誤地將其傳遞給來賓兩次。這會造成來賓核心觀察到核心權限 #GP 錯誤 (通常是嚴重錯誤)，而非使用者權限 #GP 錯誤 (通常會轉換成 SIGSEGV/ 等)。惡意或錯誤的使用者空間可造成來賓核心損毀，進而導致 VM 拒絕服務。Xen 3.2 及之後所有版本都容易受到影響。僅 x86 系統會受到影響。ARM 平台不受影響。只有在 64 位元模式下支援 SYSENTER 指令的 x86 系統容易受到影響。據信這包括 Intel、Centaur 和上海 CPU。據信 AMD 和 Hygon CPU 不會受到影響。只有 x86 PV 來賓可利用此弱點。x86 PVH / HVM 來賓無法利用此弱點。(CVE-2020-25596)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。未正確處理「已經有效的事件通道可能不會變為無效」這一限制條件。Xen 中事件通道作業的處理邏輯假設事件通道一旦有效，就不會在來賓的生命週期內變為無效。但是，在確定有效性時，諸如重設所有事件通道之類的操作可能會減少其中某一檢查邊界。這可能會導致觸發錯誤檢查，進而損毀主機。無權限的客體可能會損毀 Xen，進而導致整個系統拒絕服務。Xen 4.4 及之後所有版本都容易受到影響。Xen 4.3 及更早版本不會受到影響。只有允許不受信任來賓機建立超過預設數量之事件通道的系統，才易受攻擊。此數字取決於來賓機的架構和類型。對於 32 位元 x86 PV 來賓機，此數字為 1023；對於 64 位元 x86 PV 來賓機以及所有 ARM 來賓機，此數字為 4095。限制不受信任來賓機建立少於此數目之事件通道的系統不會受到影響。請注意，xl 和 libxl 預設將 max_event_channels 限制為 1023，因此專門使用 xl、libvirt+libxl 或其自己的以 libxl 為基礎的 toolstack 且未明確設定 max_event_channels 的系統不會受到影響。(CVE-2020-25597)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。存在 evtchn_reset() 爭用情形。使用 EVTCHNOP_reset (可能由來賓機本身) 或 XEN_DOMCTL_soft_reset (由 XSA-77 涵蓋) 可導致違反多種內部假設。這可能會導致超出邊界記憶體存取或觸發錯誤檢查。特別是，x86 PV 來賓機可能能夠將其權限提升至主機權限。另外，也有可能發生主機和來賓機當機，進而導致拒絕服務 (DoS)。無法排除資訊洩漏狀況。Xen 4.5 及之後所有版本都容易受到影響。Xen 4.4 及更早版本不會受到影響。(CVE-2020-25599)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。超出邊界事件通道可用於 32 位元 x86 網域。所謂的 2 層事件通道模型會對 32 位元 x86 網域和 64 位元或 Arm (任一個位元組) 網域可用的事件通道數量施加不同限制。 32 位元 x86 網域只能使用 1023 個通道，這是因為其共用 (來賓和 Xen 之間) 資訊結構中的空間有限所致，而在此模型中，所有其他網域最多可使用 4095 個通道。但是，在網域初始化期間，在實際接受個別網域內容之前，只要網域仍然被視為 64 位元網域，程式就已經記錄了個別限制。在將網域識別為 32 位元的情況下，並未相應更新限制。由於 Xen 中的這一錯誤行為，為其他網域提供服務的 32 位元網域 (包括網域 0) 可能會觀察到事件通道配置在實際應該失敗時成功。
    後續使用此類事件通道可能會導致共用資訊結構的其他部分損毀。無權限的來賓可造成其他網域 (尤其是網域 0) 運作不當。這可導致整個系統發生拒絕服務 (DoS)。Xen 4.4 及之後所有版本都容易受到影響。Xen 4.3 版和更早版本不會受到影響。只有服務其他網域的 x86 32 位元網域容易受到影響。Arm 系統以及 x86 64 位元網域不受此弱點影響。(CVE-2020-25600)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。evtchn_reset() / evtchn_destroy() 中缺少先佔安排。特別是，FIFO 事件通道模型允許來賓機一次建立大量事件通道。(在重設所有事件通道或在來賓機建立後清理時) 關閉所有這些項目，可能會花費更長的時間。到目前為止，尚無適當間隔的先佔安排，導致 CPU 在處理這些作業時花費幾乎無限的時間。惡意或錯誤來賓核心可掛載影響整個系統的拒絕服務 (DoS) 攻擊。原則上，所有 Xen 版本都容易受到影響。Xen 4.3 版和更舊版本是否容易受到影響，取決於基礎硬體特性。(CVE-2020-25601)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。處理來賓對 MSR_MISC_ENABLE 的存取時，x86 PV 來賓可觸發主機作業系統當機。當來賓存取特定型式的專用暫存器時，Xen 首先從硬體讀取值，以作為稽核來賓存取權限的基礎。對於 MISC_ENABLE MSR (Intel 特定的 MSR)，執行此 MSR 讀取時未對 #GP 錯誤進行錯誤處理，這是嘗試在非 Intel 硬體上讀取此 MSR 的結果。存在缺陷或惡意的 PV 來賓系統管理員可造成 Xen 當機，進而導致主機拒絕服務。僅 x86 系統會受到影響。ARM 系統不受影響。只有 Xen 4.11 版及之後的版本容易受到影響。4.10 及更早版本不受此弱點影響。只有未實作 MISC_ENABLE MSR (0x1a0) 的 x86 系統容易受到影響。AMD 和 Hygon 系統未實作此 MSR，因此容易受到影響。Intel 系統實作了此 MSR，因此不會受到影響。尚未檢查其他製造商。只有 x86 PV 來賓可利用此弱點。x86 HVM/PVH 來賓無法利用此弱點。(CVE-2020-25602)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。存取/配置事件通道時缺少記憶體障礙。只要認為連接埠有效，就可以無鎖定存取事件通道控制結構。此類序列缺少適當的記憶體障礙 (例如 smp_*mb())，以防止編譯器和 CPU 重新排序存取。惡意來賓機可造成 Xen 當機，進而導致拒絕服務 (DoS)。無法排除資訊洩漏和權限提升狀況。執行所有 Xen 版本的系統皆會受到影響。系統是否易受攻擊取決於構建 Xen 所使用的 CPU 和編譯器。在所有系統中，此弱點的存在與影響範圍取決於用來構建 Xen 的編譯器所執行的精確重新排序。我們無法調查編譯器，因此無法說出哪些編譯器（使用哪些程式碼產生選項）可能產生有弱點的程式碼。GCC 文件明確指出可以重新排序。如果 CPU 能夠重新排序記憶體存取，Arm 系統也將容易受到影響。請諮詢您的 CPU 供應商。x86 系統只有在編譯器執行重新排序時才會受到影響。(CVE-2020-25603)

  - 在 Xen 4.14.x 及之前版本中發現一個問題。在 x86 HVM vCPU 之間移轉計時器時發生爭用情形。在 x86 HVM 來賓機的 vCPU 之間移轉計時器時，所用的鎖定模型會允許相同來賓機的第二個 vCPU 在計時器上運作，以釋放其未取得的鎖定。此問題最可能造成的影響是 Hypervisor 懸置或損毀，即拒絕服務 (DoS)。所有 Xen 版本皆會受到影響。僅 x86 系統會受到影響。Arm 系統不受影響。只有 x86 HVM 來賓機可利用此弱點。x86 PV 和 PVH 無法利用此弱點。只有具有多個 vCPU 的來賓機才能惡意利用此弱點。(CVE-2020-25604)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

在 Xen hypervisor 中發現多個弱點，會造成拒絕服務、來賓權限提升為主機權限或資訊洩漏。

ID	名稱	產品	系列	已發布	已更新	嚴重性
150180	OracleVM 3.4：xen (OVMSA-2021-0014)	Nessus	OracleVM Local Security Checks	2021/6/3	2022/5/9	high
144857	Xen 的 evtchn_reset() / evtchn_destroy() 中缺少先佔 DoS (XSA-344)	Nessus	Misc.	2021/1/12	2021/6/3	medium
165248	Ubuntu 20.04 LTS：Xen 弱點 (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2023/7/12	high
141138	Debian DSA-4769-1：xen - 安全性更新	Nessus	Debian Local Security Checks	2020/10/5	2024/2/16	high

偵測

搜尋 Plugin

high

medium

high

high