远程主机受到 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 虚拟机监控程序受到 x86 上 IOMMU 页面映射中的多个漏洞影响。
 AMD 和 Intel 都允许 ACPI 表指定应保留未转换的内存区域，这通常意味着这些地址可以不经更改便通过转换阶段。虽然这些通常是设备特定的 ACPI 属性，但也可以将其指定为应用于一系列设备，甚至是所有设备。在所有具有此类区域的系统上，Xen 无法阻止客户机撤消/替换此类映射。

  在所有具有此类区域的系统上，Xen 无法阻止客户机撤消/替换此类映射。(CVE-2021-28694)

  在 AMD 系统上，固件指定了不连续的范围，本应被排除的中间范围也将进行身份映射。(CVE-2021-28695)

  此外，在 AMD 系统上，从客户机取消分配物理设备时，身份映射将保留在原位，从而允许客户机继续访问其不应再访问的内存范围。(CVE-2021-28696)

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

远程 Debian 11 主机上安装的多个程序包受到 dsa-4977 公告中提及的多个漏洞影响。

  - 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)

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

远程 OracleVM 系统缺少解决关键安全更新的必要补丁：

  - 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)

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

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
164116	GLSA-202208-23：Xen：多个漏洞	Nessus	Gentoo Local Security Checks	2022/8/15	2023/10/16	high
159518	x86 上的 Xen IOMMU 页面映射问题 (XSA-378)	Nessus	Misc.	2022/4/5	2022/4/27	medium
153509	Debian DSA-4977-1：xen - 安全更新	Nessus	Debian Local Security Checks	2021/9/21	2022/5/9	high
154015	OracleVM 3.4：xen (OVMSA-2021-0033)	Nessus	OracleVM Local Security Checks	2021/10/12	2022/5/9	high

检测

插件搜索

high

medium

high

high