According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by a vulnerability in the IOMMU that fails to strip tables in shared page table mode. The vulnerability only affects x86 Intel systems. A local, authorized attacker could use this vulnerability to escalate from guest to host privilages.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version   number.

The remote host is affected by the vulnerability described in GLSA-202208-23 (Xen: Multiple Vulnerabilities)

  - IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains     which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify     regions of memory which should be left untranslated, which typically means these addresses should pass the     translation phase unaltered. While these are typically device specific ACPI properties, they can also be     specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed     to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a     discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-     mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the     identity mappings would be left in place, allowing a guest continued access to ranges of memory which it     shouldn't have access to anymore (CVE-2021-28696). (CVE-2021-28694, CVE-2021-28695, CVE-2021-28696)

  - grant table v2 status pages may remain accessible after de-allocation Guest get permitted access to     certain Xen-owned pages of memory. The majority of such pages remain allocated / associated with a guest     for its entire lifetime. Grant table v2 status pages, however, get de-allocated when a guest switched     (back) from v2 to v1. The freeing of such pages requires that the hypervisor know where in the guest these     pages were mapped. The hypervisor tracks only one use within guest space, but racing requests from the     guest to insert mappings of these pages may result in any of them to become mapped in multiple locations.
    Upon switching back from v2 to v1, the guest would then retain access to a page that was freed and perhaps     re-used for other purposes. (CVE-2021-28697)

  - long running loops in grant table handling In order to properly monitor resource use, Xen maintains     information on the grant mappings a domain may create to map grants offered by other domains. In the     process of carrying out certain actions, Xen would iterate over all such entries, including ones which     aren't in use anymore and some which may have been created but never used. If the number of entries for a     given domain is large enough, this iterating of the entire table may tie up a CPU for too long, starving     other domains or causing issues in the hypervisor itself. Note that a domain may map its own grants, i.e.
    there is no need for multiple domains to be involved here. A pair of cooperating guests may, however,     cause the effects to be more severe. (CVE-2021-28698)

  - inadequate grant-v2 status frames array bounds check The v2 grant table interface separates grant     attributes from grant status. That is, when operating in this mode, a guest has two tables. As a result,     guests also need to be able to retrieve the addresses that the new status tracking table can be accessed     through. For 32-bit guests on x86, translation of requests has to occur because the interface structure     layouts commonly differ between 32- and 64-bit. The translation of the request to obtain the frame numbers     of the grant status table involves translating the resulting array of frame numbers. Since the space used     to carry out the translation is limited, the translation layer tells the core function the capacity of the     array within translation space. Unfortunately the core function then only enforces array bounds to be     below 8 times the specified value, and would write past the available space if enough frame numbers needed     storing. (CVE-2021-28699)

  - xen/arm: No memory limit for dom0less domUs The dom0less feature allows an administrator to create     multiple unprivileged domains directly from Xen. Unfortunately, the memory limit from them is not set.
    This allow a domain to allocate memory beyond what an administrator originally configured.
    (CVE-2021-28700)

  - Another race in XENMAPSPACE_grant_table handling Guests are permitted access to certain Xen-owned pages of     memory. The majority of such pages remain allocated / associated with a guest for its entire lifetime.
    Grant table v2 status pages, however, are de-allocated when a guest switches (back) from v2 to v1. Freeing     such pages requires that the hypervisor enforce that no parallel request can result in the addition of a     mapping of such a page to a guest. That enforcement was missing, allowing guests to retain access to pages     that were freed and perhaps re-used for other purposes. Unfortunately, when XSA-379 was being prepared,     this similar issue was not noticed. (CVE-2021-28701)

  - PCI devices with RMRRs not deassigned correctly Certain PCI devices in a system might be assigned Reserved     Memory Regions (specified via Reserved Memory Region Reporting, RMRR). These are typically used for     platform tasks such as legacy USB emulation. If such a device is passed through to a guest, then on guest     shutdown the device is not properly deassigned. The IOMMU configuration for these devices which are not     properly deassigned ends up pointing to a freed data structure, including the IO Pagetables. Subsequent     DMA or interrupts from the device will have unpredictable behaviour, ranging from IOMMU faults to memory     corruption. (CVE-2021-28702)

  - certain VT-d IOMMUs may not work in shared page table mode For efficiency reasons, address translation     control structures (page tables) may (and, on suitable hardware, by default will) be shared between CPUs,     for second-level translation (EPT), and IOMMUs. These page tables are presently set up to always be 4     levels deep. However, an IOMMU may require the use of just 3 page table levels. In such a configuration     the lop level table needs to be stripped before inserting the root table's address into the hardware     pagetable base register. When sharing page tables, Xen erroneously skipped this stripping. Consequently,     the guest is able to write to leaf page table entries. (CVE-2021-28710)

  - Incomplete cleanup of multi-core shared buffers for some Intel(R) Processors may allow an authenticated     user to potentially enable information disclosure via local access. (CVE-2022-21123)

  - Incomplete cleanup of microarchitectural fill buffers on some Intel(R) Processors may allow an     authenticated user to potentially enable information disclosure via local access. (CVE-2022-21125)

  - Incomplete cleanup in specific special register write operations for some Intel(R) Processors may allow an     authenticated user to potentially enable information disclosure via local access. (CVE-2022-21166)

  - arm: guest_physmap_remove_page not removing the p2m mappings The functions to remove one or more entries     from a guest p2m pagetable on Arm (p2m_remove_mapping, guest_physmap_remove_page, and p2m_set_entry with     mfn set to INVALID_MFN) do not actually clear the pagetable entry if the entry doesn't have the valid bit     set. It is possible to have a valid pagetable entry without the valid bit set when a guest operating     system uses set/way cache maintenance instructions. For instance, a guest issuing a set/way cache     maintenance instruction, then calling the XENMEM_decrease_reservation hypercall to give back memory pages     to Xen, might be able to retain access to those pages even after Xen started reusing them for other     purposes. (CVE-2022-23033)

  - A PV guest could DoS Xen while unmapping a grant To address XSA-380, reference counting was introduced for     grant mappings for the case where a PV guest would have the IOMMU enabled. PV guests can request two forms     of mappings. When both are in use for any individual mapping, unmapping of such a mapping can be requested     in two steps. The reference count for such a mapping would then mistakenly be decremented twice. Underflow     of the counters gets detected, resulting in the triggering of a hypervisor bug check. (CVE-2022-23034)

  - Insufficient cleanup of passed-through device IRQs The management of IRQs associated with physical devices     exposed to x86 HVM guests involves an iterative operation in particular when cleaning up after the guest's     use of the device. In the case where an interrupt is not quiescent yet at the time this cleanup gets     invoked, the cleanup attempt may be scheduled to be retried. When multiple interrupts are involved, this     scheduling of a retry may get erroneously skipped. At the same time pointers may get cleared (resulting in     a de-reference of NULL) and freed (resulting in a use-after-free), while other code would continue to     assume them to be valid. (CVE-2022-23035)

  - x86 pv: Race condition in typeref acquisition Xen maintains a type reference count for pages, in addition     to a regular reference count. This scheme is used to maintain invariants required for Xen's safety, e.g.
    PV guests may not have direct writeable access to pagetables; updates need auditing by Xen. Unfortunately,     the logic for acquiring a type reference has a race condition, whereby a safely TLB flush is issued too     early and creates a window where the guest can re-establish the read/write mapping before writeability is     prohibited. (CVE-2022-26362)

  - x86 pv: Insufficient care with non-coherent mappings T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen maintains a type     reference count for pages, in addition to a regular reference count. This scheme is used to maintain     invariants required for Xen's safety, e.g. PV guests may not have direct writeable access to pagetables;
    updates need auditing by Xen. Unfortunately, Xen's safety logic doesn't account for CPU-induced cache non-     coherency; cases where the CPU can cause the content of the cache to be different to the content in main     memory. In such cases, Xen's safety logic can incorrectly conclude that the contents of a page is safe.
    (CVE-2022-26363, CVE-2022-26364)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

自己報告のバージョン番号によると、リモートホストにインストールされている Xen ハイパーバイザーは、IOMMU の脆弱性の影響を受け、共有ページテーブルモードでテーブルを取り除くことに失敗します。この脆弱性は x86 Intel システムにのみ影響します。ローカルの承認された攻撃者がこの脆弱性を利用して、ゲストからホストの権限に昇格する可能性があります。

Nessus はこの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ頼っていることに注意してください。

远程主机受到 GLSA-202208-23 中所述漏洞的影响（Xen：多个漏洞）

  - x86 上的 IOMMU 页面映射问题 T[其 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE]。AMD 和 Intel 都允许 ACPI 表指定应当保留不转换的内存区域，这通常意味着这些地址应经过转换但不进行更改。虽然这些通常是设备特定的 ACPI 属性，但也可以将其指定为应用于一系列设备，甚至是所有设备。在所有具有此类区域的系统上，Xen 无法阻止客户机撤消/替换此类映射 (CVE-2021-28694)。在 AMD 系统上，固件指定了不连续的范围，本应被排除的中间范围也将进行身份映射 (CVE-2021-28695)。此外，在 AMD 系统上，从客户机取消分配物理设备时，身份映射将保留在原位，从而允许客户机继续访问其不应再访问的内存范围 (CVE-2021-28696)。(CVE-2021-28694、CVE-2021-28695、CVE-2021-28696)

  - 在取消分配客户机获得对某些 Xen 拥有的内存页面的访问权限后，授予表 v2 状态页面仍可访问。大多数此类页面在其整个生命周期内都会保持与客户机的分配/关联关系。但是，当客户机从 v2 切换（返回）到 v1 时，授予表 v2 状态页会被取消分配。释放这些页面需要管理程序知道这些页面在客户机中的具体映射位置。管理程序仅跟踪客户机空间中的一个使用，但客户机要求插入这些页面的映射的争用请求可能导致其中任何一个页面被映射到多个位置。
    从 v2 切换回 v1 时，客户机将保留对已释放页面的访问权限，并可能将其重新用于其他目的。(CVE-2021-28697)

  - 授权表处理中的长运行循环 为正确监控资源使用，Xen 会维护有关授权映射（域可能将其创建用于映射其他域提供的授权）的信息。在执行某些操作的过程中，Xen 会迭代所有此类条目，包括不再使用的条目以及一些可能已创建但从未使用的条目。如果给定域的条目数足够多，则整个表的迭代可能占用 CPU 太久，导致其他域缺乏 CPU 或导致管理程序本身出现问题。请注意，域可以映射自己的授权，即
    此情况下无需使用多个域。但是，两台合作的客户机可能造成更严重的影响。(CVE-2021-28698)

  - grant-v2 状态框架数组边界检查不充分 v2 授予表接口会将授予属性与授予状态分开。即，在此模式下操作时，客户机具有两个表。因此，客户机还需要能够检索可通过其访问新状态跟踪表的地址。对于 x86 上的 32 位客户机，必须转换请求，这是因为 32 位和 64 位之间的界面结构布局通常不同。若要转换获得授予状态表的帧号的请求，需要转换帧号的结果数组。由于用于执行转换的空间有限，转换层会将转换空间内的数组容量告知 core 函数。但遗憾的是，core 函数随后只会强制执行低于指定值的 8 倍的数组边界，并且如果需要存储足够的帧号，则写入会超出可用空间。(CVE-2021-28699)

  - xen/arm：dom0less domUs 无内存限制 dom0less 功能允许管理员直接从 Xen 创建多个非特权域。遗憾的是，并未设置这些域的内存限制。
    这将允许域分配超出管理员最初配置的内存。
    (CVE-2021-28700)

  - XENMAPSPACE_grant_table 处理进程中的另一个争用条件 允许客户机访问某些 Xen 拥有的内存页面。大多数此类页面在其整个生命周期内都会保持与客户机的分配/关联关系。
    但是，当客户机从 v2 切换（返回）到 v1 时，授予表 v2 状态页会被取消分配。释放此类页面需要管理程序强制执行任何并行请求都不能导致添加此类页面的映射到客户机。缺少该强制执行时，系统将允许客户机保留对已释放页面的访问权限，并可能将其重新用于其他目的。遗憾的是，在准备 XSA-379 时，并未注意到此类似问题。(CVE-2021-28701)

  - 未正确取消分配 RMRR 的 PCI 设备可能会为系统中的某些 PCI 设备分配预留内存区域（通过“预留内存区域报告 (RMRR)”指定）。这些设备通常用于执行平台任务，例如旧版 USB 仿真。如果将此类设备传递给客户机，则客户机关闭时，该设备不会正确取消分配。这些未正确取消分配的设备的 IOMMU 配置最终会指向一个已释放的数据结构，包括 IO 页表。来自设备的后续 DMA 或中断将表现不可预测的行为，范围从 IOMMU 错误到内存损坏。(CVE-2021-28702)

  - 某些 VT-d IOMMU 可能无法在共享页表模式下工作。出于效率原因，对于二级转换 (EPT) ，程序可能在 CPU 之间和 IOMMU 之间共享（在适当的硬件上，默认会共享）地位转换控制结构（页表）。这些页表目前设置为始终为 4 级深度，但 IOMMU 可能只需要使用 3 个页表级别。在这样的配置中，需要剥离 lop 级表格，然后将根表的地址插入硬件页表基址寄存器。共享页表时，Xen 会错误地跳过此剥离操作。因此，来宾能够写入叶页表条目。(CVE-2021-28710)

  - 在某些 Intel(R) 处理器中，多核心共享缓冲区若清理不完全，经过身份验证的用户可能会通过本地访问泄露信息。(CVE-2022-21123)

  - 在某些 Intel(R) 处理器中，微架构填充缓冲区若清理不完全，经过身份验证的用户可能会通过本地访问泄露信息。(CVE-2022-21125)

  - 对于某些 Intel(R) 处理器，特定的特殊寄存器写入操作若清理不完全，经过身份验证的用户可能会通过本地访问泄露信息。(CVE-2022-21166)

  - arm：guest_physmap_remove_page 未删除 p2m 映射。如果条目不具有有效的位集，则用于从 Arm 上的来宾 p2m 页表删除一个或多个条目的函数（mfn 设置为 INVALID_MFN 的 p2m_remove_mapping、guest_physmap_remove_page 和 p2m_set_entry）实际并未清除该页表条目。当来宾操作系统使用 set/way 缓存维护指令时，可能会有没有有效位集的有效页表条目。例如，来宾发出 set/way 缓存维护指令，然后调用 XENMEM_decrease_reservation 超级调用以便向 Xen 返回内存页，即使在 Xen 开始将这些页面用于其他目的之后，该来宾仍可能保留对这些页面的访问权限。(CVE-2022-23033)

  - 在取消映射授权时，PV 来宾上的 Xen 可能发生 DoS。为应对 XSA-380，在 PV 来宾启用 IOMMU 的情况下，为授权映射引入了引用计数。PV 来宾可请求两种形式的映射。当两者同时用于任何单独的映射时，可以分两个步骤请求取消映射。这样，一个映射的引用计数会错误地递减两次。检测到计数器下溢，从而触发虚拟机监控程序缺陷检查。(CVE-2022-23034)

  - 传递设备 IRQ 的清理不充分。与暴露给 x86 HVM 来宾的物理设备相关联的 IRQ 管理涉及迭代操作，尤其是在来宾使用设备之后进行清理时。如果调用此清理时中断尚未停止，则程序可能会计划重试清理操作。当涉及多个中断时，可能会错误地跳过此重试计划。同时，指针可能会被清除（导致取消引用 NULL 指针）和释放（导致释放后使用），而其他代码会继续假设它们有效。(CVE-2022-23035)

  - x86 pv：除了常规引用计数外，typeref 获取 Xen 中的争用条件还会维护页面的类型引用计数。此方案用于维护 Xen 安全所需的不变量，例如
    PV 来宾机可能不具有页表的直接可写访问权限；如需更新，需经 Xen 审核。遗憾的是，用于获取类型引用的逻辑存在争用条件，因此安全的 TLB 刷新过早发出，并创建了一个窗口，客户机可在该窗口中重新建立读取/写入映射，然后再禁止可写性。(CVE-2022-26362)

  - x86 pv：对非连贯映射重视不足 [此类 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞与哪些 CVE 对应。] 除了常规引用计数外，Xen 还维护页面的类型引用计数。此方案用于维护 Xen 安全所需的不变量，例如 PV 来宾机可能不具有页表的直接可写访问权限；
    如需更新，需经 Xen 审核。遗憾的是，Xen 的安全逻辑未考虑 CPU 引起的缓存非一致性；CPU 可导致缓存内容与主内存不一致的情况。在此类情况下，Xen 的安全逻辑可能会错误地断定页面内容安全。
    （CVE-2022-26363、CVE-2022-26364）

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

根据其自我报告的版本号，远程主机上安装的 Xen 虚拟机监控程序受到 IOMMU 中的一个漏洞影响，即无法在共享页表模式下删除表。此漏洞仅影响 x86 Intel 系统。获授权的本地攻击者可利用此漏洞，从客户机权限升级为主机权限。

请注意，Nessus 尚未测试此问题，而是只依靠应用程序自我报告的版本号来判断。

根據其自我報告的版本號碼，遠端主機上安裝的 Xen Hypervisor 受到 IOMMU 中的一個弱點影響，即無法在公用頁面表格模式下刪除表格。此弱點僅會影響 x86 Intel 系統。經授權的本機攻擊者可利用此弱點將來賓權限提升至主機權限。

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

遠端主機受到 GLSA-202208-23 中所述的弱點影響 (Xen：多個弱點)

  - x86 上的 IOMMU 頁面對應問題 [其 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應於哪個 CVE] 。AMD 和 Intel 都允許 ACPI 表格指定不應轉譯的記憶體區域，這通常表示這些位址應在不作變更的情況下完成轉譯。雖然這些通常是裝置特定的 ACPI 屬性，但也可以將其指定為套用至一系列裝置，甚至是所有裝置。在所有具有此類區域的系統上，Xen 無法防止來賓機復原/取代此類對應 (CVE-2021-28694)。在 AMD 系統上，韌體指定了不連續的範圍，本應排除的中間範圍也將進行身分對應 (CVE-2021-28695)。此外，在 AMD 系統上，從來賓機解除指派實體裝置時，身分對應會保留在原位，來賓機可繼續存取不應再有存取權的記憶體範圍 (CVE-2021-28696)。(CVE-2021-28694、CVE-2021-28695、CVE-2021-28696)

  - 在取消配置來賓機獲得某些 Xen 擁有的記憶體頁面的存取權後，授予表格 v2 狀態頁面仍可存取。大多數此類頁面在其整個生命週期內都會保持與來賓機的配置/關聯關係。但是，當來賓機從 v2 切換 (返回) 到 v1 時，授權表 v2 狀態頁面會解除配置。釋放這類頁面需要 Hypervisor 知道這些頁面在來賓機中的具體對應位置。Hypervisor 只追踪來賓機空間中的一個使用，但來賓機請求插入這些頁面的對應的爭用要求，可能導致其中任何一個頁面變成在多個位置進行對應。
    當從 v2 切換回 v1 時，來賓機會保留對已釋放頁面的存取權，而且可能會將其重新用於其他目的。(CVE-2021-28697)

  - 授權表處理中的長時間執行迴圈 為正確監控資源使用，Xen 會維護網域可能建立的與其他網域提供的授權進行對應的授權對應資訊。在執行特定動作的過程中，Xen 會反覆使用所有這類項目，包括不再使用的項目，以及可能已建立但從未使用過的一些項目。如果指定網域的項目數量足夠大，則整個表格的反覆使用進程可能會佔用 CPU 太久，進而造成其他網域缺乏 CPU，或造成 Hypervisor 本身出現問題。請注意，網域可能會對應自己的授權，即
    此情況下不需要涉及多個網域。然而，一對合作的來賓機可能會造成更嚴重的影響。(CVE-2021-28698)

  - 不充分的 grant-v2 狀態框架陣列邊界檢查 v2 授權表格介面將授權屬性與授權狀態分開。也就是說，在此模式下操作時，來賓有兩個表格。因此，來賓也需要能夠擷取可用來存取新狀態追蹤表的位址。對於 x86 上的 32 位元來賓，因為 32 位元和 64 位元的介面結構配置通常不同，所以必須進行要求轉譯。轉譯取得授權狀態表格框架編號的要求時，涉及轉譯框架編號的結果陣列。由於用於執行轉譯的空間有限，轉譯層會將轉譯空間內的陣列容量告知核心函式。但遺憾的是，核心函式只會強制陣列邊界低於指定值的 8 倍，如果需要儲存足夠的框架編號，還會在可用空間之外寫入。(CVE-2021-28699)

  - xen/arm：dom0less domUs 沒有記憶體限制 dom0less 功能允許系統管理員直接從 Xen 建立多個無權限的網域，遺憾的是，由於尚未設定記憶體限制，
    這將允許網域配置超出系統管理員原本設定的記憶體。
    (CVE-2021-28700)

  - XENMAPSPACE_grant_table 處理中的另一個爭用情形，允許來賓機存取某些 Xen 擁有的記憶體頁面。大多數此類頁面在其整個生命週期內都會保持與來賓機的配置/關聯關係。
    但是，當來賓機從 v2 切換 (返回) 到 v1 時，授權表 v2 狀態頁面會解除配置。釋放這類頁面需要 Hypervisor 強制執行任何平行要求都不會導致新增此類頁面的對應到來賓機。如果缺少強制執行，則將允許來賓機保留對已釋放頁面的存取權，並且可能將其重新用於其他目的。遺憾的是，在準備 XSA-379 時，並未註意到與此相似的問題。(CVE-2021-28701)

  - 針對未正確取消指派 RMRR 的 PCI 裝置，系統中的某些 PCI 裝置可能指派保留記憶體區域 (透過保留記憶體區域報告 (RMRR) 指定)。這些裝置通常用於平台工作，例如傳統 USB 模擬。如果將此類裝置傳遞給來賓，則在來賓關機時，裝置不會正確解除指派。未正確解除指派的這些裝置的 IOMMU 組態最終指向已釋放的資料結構，包括 IO 頁表。來自裝置的後續 DMA 或中斷將有無法預測的行為，涵蓋範圍從 IOMMU 錯誤到記憶體損毀。(CVE-2021-28702)

  - 某些 VT-d IOMMU 可能無法在共用分頁表模式下運作。出於效率原因，對於二級轉譯 (EPT)，程式可在 CPU 和 IOMMU 之間共用 (在合適的硬體上，也會預設共用) 位址轉譯結構 (分頁表)。這些分頁表目前設定一律為 4 級深度，但 IOMMU 可能只需要使用 3 個分頁表層級。在此類組態中，必須先去除 lop 層級表格，然後再將 root 表格的位址插入硬體分頁表基址暫存器中。共用分頁表時，Xen 會錯誤地略過此去除作業。因此，來賓可以寫入分頁表項目。 (CVE-2021-28710)

  - 在某些 Intel(R) 處理器中，多核心共用緩衝區若清理不完全，經驗證的使用者則可能透過本機存取造成資訊洩漏。(CVE-2022-21123)

  - 在某些 Intel(R) 處理器中，微架構填補緩衝區若清理不完全，經驗證的使用者則可能透過本機存取造成資訊洩漏。(CVE-2022-21125)

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

  - arm：guest_physmap_remove_page 未移除 p2m 對應。若項目沒有有效的位元集，則用於從 Arm 上的客體 p2m 分頁表移除一或多個項目的函式 (mfn 設定為 INVALID_MFN 的 p2m_remove_mapping、guest_physmap_remove_page 和 p2m_set_entry) 並未實際清除分頁表項目。當虛擬機器上的作業系統使用 set/way 快取維護指示時，可能會有沒有有效位元集的有效分頁表項目。例如，客體發出 set/way 快取維護指令，然後呼叫 XENMEM_decrease_reservation hypercall 以將記憶體頁面傳回給 Xen，即使在 Xen 開始將這些頁面用於其他目的之後，此客體仍可能保留對這些頁面的存取權。(CVE-2022-23033)

  - 在取消對應時，PV 客體中的 Xen 可能發生 DoS。為解決 XSA-380，在 PV 客體啟用 IOMMU 的情況下，爲授權對應引入了參照計數。PV 客體可要求兩種形式的對應。當兩者同時用於任何個別的對應時，可以分兩個步驟要求取消對應。此類對應的參照計數會錯誤地遞減兩次。偵測到計數器反向溢位，進而觸發 Hypervisor 錯誤檢查。(CVE-2022-23034)

  - 傳遞裝置 IRQ 的清理不充分。與公開給 x86 HVM 客體的實體裝置相關聯的 IRQ 管理涉及反覆作業，特別是在客體使用裝置後進行清理時。如果在呼叫此清理時中斷尚未停止，則程式可能會排程重試清理作業。當涉及多次中斷時，可能會錯誤地略過此重試排程。同時，指標可能會被清除 (導致 NULL 指標解除參照) 和釋放 (導致釋放後使用)，而其他程式碼會繼續假設它們有效。(CVE-2022-23035)

  - x86 pv：取得 typeref 時會發生爭用情形。除了一般參照計數外，Xen 還會爲頁面保留類型參照計數。此配置用於保留確保 Xen 安全性所需的不變量，例如：
    PV 來賓可能沒有對頁面表格的直接寫入存取權；更新需要 Xen 稽核。但遺憾的是，用於取得類型參照的邏輯存在爭用情形，程式可過早發出安全清除 TLB 命令並建立一個視窗，來賓可在寫入操作被禁止前在該視窗中重新建立讀取/寫入對應。(CVE-2022-26362)

  - x86 pv：未充分注意非一致對應 [此 CNA 資訊記錄與多個 CVE 有關，文中說明了哪些方面/弱點對應哪個 CVE。] 除了一般的參照計數，Xen 還會保留頁面的類型參照計數。此配置用於維護確保 Xen 安全所需的不變量，例如 PV 來賓可能沒有對頁面表格的直接寫入存取權；
    更新需要 Xen 稽核。但遺憾的是，Xen 的安全邏輯並未考慮由 CPU 引起的快取不一致性；CPU 可造成快取內容與主記憶體中內容不同的情況。在這種情況下，Xen 的安全邏輯可能會錯誤判斷頁面內容是否安全。
    (CVE-2022-26363、CVE-2022-26364)

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

ID	Name	Product	Family	Published	Updated	Severity
156325	Xen Certain VT-d IOMMUs May Not Work In Shared Page Table Mode (XSA-390)	Nessus	Misc.	12/28/2021	11/21/2022	high
164116	GLSA-202208-23 : Xen: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	8/15/2022	10/16/2023	high
156325	Xen 特定の VT-d IOMMU が共有ページテーブルモードで動作しない (XSA-390)	Nessus	Misc.	12/28/2021	11/21/2022	high
164116	GLSA-202208-23：Xen：多个漏洞	Nessus	Gentoo Local Security Checks	8/15/2022	10/16/2023	high
156325	Xen 的特定 VT-d IOMMU 在共享页表模式下可能无法正常工作 (XSA-390)	Nessus	Misc.	12/28/2021	11/21/2022	high
156325	Xen 的特定 VT-d IOMMU 可能無法在共用頁面表格模式下運作 (XSA-390)	Nessus	Misc.	12/28/2021	11/21/2022	high
164116	GLSA-202208-23：Xen：多個弱點	Nessus	Gentoo Local Security Checks	8/15/2022	10/16/2023	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high

high