根据其自我报告的版本号，远程主机上安装的 Xen 虚拟机监控程序受到拒绝服务 (DoS) 漏洞的影响。当在 x86 HVM 客户机的 vCPU 之间迁移计时器时，所使用的锁定模型允许也在定时器上操作的相同客户机的第二个 vCPU 释放其未获取的锁定。攻击者可利用此问题造成管理程序崩溃并造成 DoS 情况。

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

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

  - 在 4.14.x 及之前的 Xen 中发现一个问题。PCI passthrough 代码不会正确使用寄存器数据。
    已确定 Xen 的 MSI 处理进程中的代码路径，这些路径作用于从设备硬件寄存器读回的未净化值。虽然严格遵守 PCI 规范的设备理应不会影响这些寄存器，但实践证明，设备中不符合规范但可影响此类读取结果的“后门”操作其实非常常见。未获完全信任的来宾用户可能造成 Xen 崩溃，并导致整个系统拒绝服务 (DoS)。不能排除特权升级和信息泄露。所有支持 PCI passthrough 的 Xen 版本都会受到影响。只有 x86 系统易受影响。Arm 系统不易受影响。只有已成功透传 PCI 设备的客户机才能利用此漏洞。只有通过具有不合规范（后门）功能的设备的系统才会造成问题。实践证明，这种不符合规范的功能很常见；除非您有理由相信设备不具备此类功能，否则最好假设它有。(CVE-2020-25595)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。存在错误处理“生效后的事件通道不会变为无效”这一限制。Xen 中处理事件通道操作的逻辑假设，生效后的事件通道不会在来宾用户生命周期内不会变为无效。但在确定有效性时，重置所有事件通道之类的操作可能包含缩小其中一个检查界限。这可能会导致触发错误检查程序，从而造成主机崩溃。无权限的来宾用户可能会引发 Xen 崩溃，从而导致整个系统拒绝服务 (DoS)。从 4.4 开始的所有 Xen 版本都容易受到影响。Xen 4.3 及之前版本不受影响。只有符合以下条件的系统才会受到攻击：具有不受信任的来宾用户，且该用户获准创建的事件通道数目多于默认值。该数字取决于来宾用户的架构和类型。若为 32 位 x86 PV 来宾用户，此数字为 1023；若为 64 位 x86 PV 来宾用户以及所有 ARM 来宾用户，此数字为 4095。如果系统将不受信任的来宾用户数限制为少于此数字，则其不易受到攻击。请注意，xl 和 libxl 默认将 max_event_channels 限制为 1023，因此仅使用 xl、libvirt+libxl 或其自己的工具堆栈基于 libxl 且未明确设置 max_event_channels 的系统将不易受到攻击。(CVE-2020-25597)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。存在多个 evtchn_reset() 争用条件。使用 EVTCHNOP_reset（可能来宾用户自身使用）或 XEN_DOMCTL_soft_reset（由 XSA-77 涵盖）可导致违反各种内部假设。而此类违反行为有可能导致越界内存访问错误或触发错误检查问题。特别是，x86 PV 来宾用户可将其权限升级至主机权限。此外，主机和来宾有可能崩溃，进而造成拒绝服务 (DoS)。而且，无法排除发生信息泄露的可能性。从 4.5 开始的所有 Xen 版本都容易受到影响。Xen 4.4 及之前版本不受影响。(CVE-2020-25599)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。越界事件通道可用于 32 位 x86 域。所谓的 2 级事件通道模型对 32 位 x86 域和 64 位或 Arm（任意位）域中可用事件通道的数量施加不同限值。32 位 x86 域只能使用 1023 条通道，这是其共享（客户机与 Xen 之间）信息结构中的空间有限所致，而此模型中的所有其他域最多可使用 4095 条通道。但是，在域初始化期间记录各自限值的时间为实际遵守各自的域属性之前，此时，域仍被视为 64 位域。当域被识别为 32 位域时，该限值并未相应更新。由于 Xen 中的这一错误行为，为其他域服务的 32 位域（包括域 0）可能会在真正失败时观察到事件通道分配成功。
    此类事件通道的后续使用可能会导致共享信息结构的其他部分损坏。非特权客户机可能造成另一个域（尤其是域 0）行为不当。这可能会导致整个系统发生拒绝服务 (DoS)。从 4.4 开始的所有 Xen 版本都容易受到影响。Xen 4.3 及之前版本不受影响。只有为其他域提供服务的 x86 32 位域容易受到攻击。Arm 系统以及 x86 64 位域不易受到攻击。(CVE-2020-25600)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。evtchn_reset() / evtchn_destroy() 缺少抢占式多任务处理。特别是，FIFO 事件通道模型允许来宾用户同时启用大量活动的事件通道。（在重置所有事件通道时或在来宾用户之后进行清理时）关闭所有这些内容可能要花费很长时间。目前尚未在适当的时间间隔安排抢占式多任务处理，这使得 CPU 可以花费几乎无限制的时间来处理这些操作。恶意的或有缺陷的客户机内核可发起拒绝服务 (DoS) 攻击，这会影响整个系统。原则上，所有 Xen 版本都容易受到攻击。Xen 4.3 及更旧版本是否易受攻击取决于底层硬件特性。(CVE-2020-25601)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。访问/分配事件通道时缺少内存屏障。只要端口有效，就可以对事件通道控制结构进行无锁访问。此类序列缺少适当的内存屏障（例如 smp_*mb()），以防止编译器和 CPU 重新排列访问顺序。恶意客户机可造成虚拟机监控程序崩溃，进而导致拒绝服务 (DoS)。而且，不能排除发生权限升级和信息泄露的可能性。运行所有 Xen 版本的系统都会受到影响。系统是否容易受到攻击取决于用于构建 Xen 的 CPU 和编译器。对所有系统而言，漏洞是否存在及影响范围取决于构建 Xen 时所用编译器执行的精确重新排序。我们无法调查编译器，因此无法断定哪个编译器（通过哪个代码生成选项）可能生成易受攻击的代码。GCC 文档明确指出可以进行重新排序。如果 CPU 能够重新排序内存访问，Arm 系统也将容易受到攻击。请咨询 CPU 供应商。x86 系统仅在编译器执行重新排序时易受攻击。(CVE-2020-25603)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。在 x86 HVM vCPU 之间迁移计时器时存在争用条件。当在 x86 HVM 客户机的 vCPU 之间迁移计时器时，所使用的锁定模型允许也在计时器上运行的相同客户机的第二个 vCPU 释放其未获取的锁定。此问题最可能造成的影响是虚拟机监控程序挂起或崩溃，即拒绝服务 (DoS)。所有 Xen 版本都会受到影响。只有 x86 系统易受影响。Arm 系统不易受影响。只有 x86 HVM 客户机才能利用此漏洞。x86 PV 和 PVH 无法利用此漏洞。只有具有多个 vCPU 的客户机才能利用此漏洞。(CVE-2020-25604)

  - 在 Xen 4.14.x 及之前版本中发现一个问题，其允许 x86 HVM 和 PVH 客户机操作系统用户造成拒绝服务（数据损坏）、造成数据泄露或可能取得权限，原因是不当处理每页 IOMMU TLB 刷新的合并操作。(CVE-2020-27671)

  - 在 Xen 4.14.x 及之前版本中发现一个问题，其允许 x86 客户机操作系统用户利用争用条件（可导致与 2MiB 和 1GiB 超级页面有关的释放后使用问题），造成主机操作系统拒绝服务、损坏数据或可能取得权限。(CVE-2020-27672)

  - Xen 4.14.x 及之前版本允许客户机操作系统管理员通过在电源/能量监控接口上发动边信道攻击（也称为 Platypus 攻击）来获取敏感信息（例如来自客户机外部的 AES 密钥）。注意：只有一个逻辑独立的补丁：更改 Xen 上每个此类接口的访问控制。(CVE-2020-28368)

  - 在 Xen 4.14.x 及之前版本中发现一个问题，其允许 x86 HVM 和 PVH 客户机操作系统用户利用差一错误造成拒绝服务（堆栈损坏）、造成数据泄露或可能取得权限。注意：
    造成此问题的原因是没有正确修复 CVE-2020-27671。(CVE-2020-29040)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。xenstore 实现不会在报告 xenstore 监视事件时执行任何权限检查。客户机管理员可监视根 xenstored 节点，这样将可在每次创建、修改和删除密钥时发出通知。客户机管理员还可以使用特殊监视工具，这样将可在每次创建和破坏域时发出通知。数据可能包括：其他 VM 的数量、类型和 domid；驱动程序域的存在性与 domid；虚拟接口、区块设备、vcpu 的数量；虚拟帧缓冲区及其后端样式的存在性（例如是否存在 VNC 服务）；其他域的 Xen VM UUID；与域创建和设备设置相关的定时信息；以及关于 VM 及其设备的后端配置的一些提示。监视工具事件不包含 xenstore 中存储的值，仅包含密钥名称。客户机管理员可以观察到与其他客户机有关的非敏感域和设备生命周期事件。此类信息便于您深入了解整体系统配置（包括其他客户机的数量和一般性质），以及其他客户机的配置（包括其他客户机设备的数量和一般性质）。此类信息可能会用于商业用途，或可使其他攻击变得更容易。我们相信，敏感数据不会泄露。具体而言，我们不会泄露 VNC 密码、端口号、主机及客户机文件系统中的路径名、加密密钥或客户机内部数据。(CVE-2020-29480)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。Xenstore 节点的访问权限取决于 domid。
    遗憾的是，破坏域时不会删除已经授予的现有访问权限。这意味着使用相同 domid 创建的新域将从具有相同 domid 的先前域继承对 Xenstore 节点的访问权限。由于客户机遭到破坏时，Xen 工具会删除客户机 /local/domain/<domid> 下的所有 Xenstore 条目，因此只有仍在运行的其他客户机的 Xenstore 条目会受到影响。例如，新创建的客户机域可能读取属于先前客户机域的敏感信息。两个 Xenstore 实现（C 和 Ocaml）都容易受到攻击。(CVE-2020-29481)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。Xenstored 与客户机使用特定协议通过共享内存页面进行通信。当客户机违反此协议时，xenstored 将断开与该客户机的连接。但遗憾的是，它仅通过从 xenstored 的内部管理中删除该客户机来实现此操作，从而导致与客户机被破坏时相同的操作，包括发送 @releaseDomain 事件。@releaseDomain 事件不表示客户机已被删除。此事件的所有监视程序必须查看所有客户机的状态，才能找到已删除的客户机。若是由于域 xenstored 协议违规而生成 @releaseDomain，则因为客户机仍在运行，所以监视程序不会响应。之后，当客户机实际遭到破坏时，xenstored 不再将其存储在内部数据库中，因此将不再发送任何 @releaseDomain 事件。这可能会导致出现僵尸域；
    由于缺失事件，系统不会删除该客户机内存中的内存映射。仅在另一个域被破坏后，因为会触发另一个 @releaseDomain 事件，这时系统才会清理此僵尸域。如果违反 Xenstore 协议的客户机设备模型正在 stub-domain 中运行，从内部数据库中删除该客户机后，xenstored 中可能会发生释放后使用情况，这可能导致 xenstored 崩溃。恶意客户机可在其自身终止之后的一段时间内阻断主机的资源。具有 stub 域设备模型的客户机最终可导致 xenstored 崩溃，从而造成更严重的拒绝服务（阻止任何进一步的域管理操作）。只有 Xenstore 的 C 变体会受到影响； Ocaml 变体不受影响。只有具有 stubdom 设备模型的 HVM 客户机，才能导致严重的 DoS 情形。(CVE-2020-29483)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。当 Xenstore 监视触发时，注册该监视的 xenstore 客户端将收到一则 Xenstore 消息，其中包含已触发该监视的已修改 Xenstore 条目的路径，以及注册该监视时指定的标记。与 xenstored 的任何通信都通过 Xenstore 消息（包含消息标头和负载）完成。负载长度限制为 4096 个字节。任何导致负载超过 4096 字节的对 xenstored 的请求都将引发错误。注册监视时，负载长度限制适用所监视路径和指定标签的组合长度。由于系统也会对该路径下的所有节点触发针对特定路径的监视，监视事件消息的负载可能比注册监视所需的负载更长。使用极大标签（即，注册操作负载长度接近 4096 字节）注册监视的恶意客户机可通过在监视路径下写入 Xenstore 条目，生成负载长度大于 4096 字节的监视事件。这将导致 xenstored 中出现错误情况。此错误可导致空指针取消引用，进而造成 xenstored 崩溃。恶意客户机系统管理员可造成 xenstored 崩溃，进而导致拒绝服务。xenstored 崩溃后，域可能会继续运行，但无法执行管理操作。只有 C xenstored 会受到影响，oxenstored 不受影响。
    (CVE-2020-29484)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。记录由 Xen 维护的 per-vCPU 控制块映射的操作和将指针记录到控制块中的操作是相反的。如果看到前者已被初始化，则用户将假设后者也已可供使用。恶意的或有缺陷的客户机内核可发起影响整个系统的拒绝服务 (DoS) 攻击。(CVE-2020-29570)

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

已在 Xen 管理程序中发现多个漏洞，可导致拒绝服务、客户机到主机权限提升或信息泄露。

远程 Ubuntu 20.04 LTS 主机上安装的多个程序包受到 USN-5617-1 公告中提及的多个漏洞影响。

  在某些 Intel(R) 处理器中，来自特定的特殊寄存器读取操作的不完整清理可能会允许经过身份验证的用户通过本地访问实现信息泄露。(CVE-2020-0543)

  - 在 Xen 4.13.x 及之前的所有版本中发现一个问题，由于在读写解锁路径中缺少内存屏障，客户机操作系统用户可利用此问题造成拒绝服务或可能获得权限。读写解锁路径不包含内存屏障。在 ARM 上，这意味着系统允许处理器按照先前的操作对内存访问顺序进行重新排序。换句话说，在访问关键部分内的所有内存之前，其他处理器可能会看到解锁。因此，可能会让写入器与读取器或其他写入器同时执行关键部分。换句话说，关键部分中的许多假设（例如，检查后不能修改变量）不再安全。由于虚拟化调用（如授权表调用）中使用了读写锁定，因此恶意客户机可利用此争用问题。例如，如果同时使用 XENMAPSPACE_grant_table，则存在 Xen 泄漏内存的短时窗口。恶意客户机可造成内存泄漏或虚拟机监控程序崩溃，进而导致拒绝服务 (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 客户机操作系统用户造成虚拟机监控程序崩溃。x86 HVM 客户机上恶意视频 RAM 跟踪代码中的反向条件允许这些客户机将 Xen 取消引用保证指向未映射空间的指针。恶意或有缺陷的 HVM 客户机可能造成虚拟机监控程序崩溃，从而导致影响整个主机的拒绝服务 (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 客户机操作系统用户可利用此问题造成虚拟机监控程序崩溃。客户机使用超级调用 VCPUOP_register_vcpu_info 在虚拟机监控程序中注册共享区域。该区域将被映射到 Xen 地址空间，因此可以直接访问。在 Arm 上，使用需要特定对齐的指令访问区域。但遗憾的是，未检查客户机提供的地址是否正确对齐。因此，恶意客户机可通过传递未对齐的地址造成监控程序崩溃。恶意客户机管理员可造成虚拟机监控程序崩溃，进而导致拒绝服务 (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 及之前的所有版本中发现一个问题，由于事件通道端口分配中的错误处理不正确，客户机操作系统用户可利用此问题造成主机操作系统崩溃。事件通道端口的分配可能因多种原因而失败：(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 在某些情况下会使用一系列非原子位字段写入。根据编译器版本和优化标记不同，Xen 可能会向硬件暴露危险的部分写入 PTE，攻击者或可对此争相利用。客户机管理员甚至非特权客户机用户或可造成拒绝服务、数据损坏或者权限升级。只有使用 Intel CPU 的系统容易遭受攻击。使用 AMD CPU 的系统和 Arm 系统不易受到攻击。只有使用嵌套分页（hap，又称为嵌套分页，在此情况下也称为 Intel EPT）的系统易受攻击。- 仅 HVM 和 PVH 客户机可利用此漏洞。漏洞的存在和范围取决于构建 Xen 时所用编译器执行的精确优化。如果编译器以与源代码相同的顺序生成 (a) 单一 64 位写入，或 (b) 一系列读取-修改-写入操作，则虚拟机监控程序不易受到攻击。例如，在使用 GCC 8.3 且具有正常设置的一个测试版本中，编译器按照源代码顺序生成了多个（未锁定）读取-修改-写入操作，这些不构成漏洞。我们无法调查编译器，
    因此无法断定哪个编译器（通过哪个代码生成选项）可能生成易受攻击的代码。源代码明显违反 C 规则，因此应视为有漏洞。
    (CVE-2020-15567)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。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 拒绝服务。从 3.2 开始的所有 Xen 版本都容易受到影响。只有 x86 系统易受影响。ARM 系统不易受影响。只有在 64 位模式下支持 SYSENTER 指令的 x86 系统容易受到攻击，这包括 Intel、Centaur 和上海 CPU。AMD 和 Hygon CPU 被认为不会受到攻击。只有 x86 PV 来宾机可利用此漏洞， x86 PVH / HVM 来宾机无法利用此漏洞。(CVE-2020-25596)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。存在错误处理“生效后的事件通道不会变为无效”这一限制。Xen 中处理事件通道操作的逻辑假设，生效后的事件通道不会在来宾用户生命周期内不会变为无效。但在确定有效性时，重置所有事件通道之类的操作可能包含缩小其中一个检查界限。这可能会导致触发错误检查程序，从而造成主机崩溃。无权限的来宾用户可能会引发 Xen 崩溃，从而导致整个系统拒绝服务 (DoS)。从 4.4 开始的所有 Xen 版本都容易受到影响。Xen 4.3 及之前版本不受影响。只有符合以下条件的系统才会受到攻击：具有不受信任的来宾用户，且该用户获准创建的事件通道数目多于默认值。该数字取决于来宾用户的架构和类型。若为 32 位 x86 PV 来宾用户，此数字为 1023；若为 64 位 x86 PV 来宾用户以及所有 ARM 来宾用户，此数字为 4095。如果系统将不受信任的来宾用户数限制为少于此数字，则其不易受到攻击。请注意，xl 和 libxl 默认将 max_event_channels 限制为 1023，因此仅使用 xl、libvirt+libxl 或其自己的工具堆栈基于 libxl 且未明确设置 max_event_channels 的系统将不易受到攻击。(CVE-2020-25597)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。存在多个 evtchn_reset() 争用条件。使用 EVTCHNOP_reset（可能来宾用户自身使用）或 XEN_DOMCTL_soft_reset（由 XSA-77 涵盖）可导致违反各种内部假设。而此类违反行为有可能导致越界内存访问错误或触发错误检查问题。特别是，x86 PV 来宾用户可将其权限升级至主机权限。此外，主机和来宾有可能崩溃，进而造成拒绝服务 (DoS)。而且，无法排除发生信息泄露的可能性。从 4.5 开始的所有 Xen 版本都容易受到影响。Xen 4.4 及之前版本不受影响。(CVE-2020-25599)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。越界事件通道可用于 32 位 x86 域。所谓的 2 级事件通道模型对 32 位 x86 域和 64 位或 Arm（任意位）域中可用事件通道的数量施加不同限值。32 位 x86 域只能使用 1023 条通道，这是其共享（客户机与 Xen 之间）信息结构中的空间有限所致，而此模型中的所有其他域最多可使用 4095 条通道。但是，在域初始化期间记录各自限值的时间为实际遵守各自的域属性之前，此时，域仍被视为 64 位域。当域被识别为 32 位域时，该限值并未相应更新。由于 Xen 中的这一错误行为，为其他域服务的 32 位域（包括域 0）可能会在真正失败时观察到事件通道分配成功。
    此类事件通道的后续使用可能会导致共享信息结构的其他部分损坏。非特权客户机可能造成另一个域（尤其是域 0）行为不当。这可能会导致整个系统发生拒绝服务 (DoS)。从 4.4 开始的所有 Xen 版本都容易受到影响。Xen 4.3 及之前版本不受影响。只有为其他域提供服务的 x86 32 位域容易受到攻击。Arm 系统以及 x86 64 位域不易受到攻击。(CVE-2020-25600)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。evtchn_reset() / evtchn_destroy() 缺少抢占式多任务处理。特别是，FIFO 事件通道模型允许来宾用户同时启用大量活动的事件通道。（在重置所有事件通道时或在来宾用户之后进行清理时）关闭所有这些内容可能要花费很长时间。目前尚未在适当的时间间隔安排抢占式多任务处理，这使得 CPU 可以花费几乎无限制的时间来处理这些操作。恶意的或有缺陷的客户机内核可发起拒绝服务 (DoS) 攻击，这会影响整个系统。原则上，所有 Xen 版本都容易受到攻击。Xen 4.3 及更旧版本是否易受攻击取决于底层硬件特性。(CVE-2020-25601)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。处理客户机对 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)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。访问/分配事件通道时缺少内存屏障。只要端口有效，就可以对事件通道控制结构进行无锁访问。此类序列缺少适当的内存屏障（例如 smp_*mb()），以防止编译器和 CPU 重新排列访问顺序。恶意客户机可造成虚拟机监控程序崩溃，进而导致拒绝服务 (DoS)。而且，不能排除发生权限升级和信息泄露的可能性。运行所有 Xen 版本的系统都会受到影响。系统是否容易受到攻击取决于用于构建 Xen 的 CPU 和编译器。对所有系统而言，漏洞是否存在及影响范围取决于构建 Xen 时所用编译器执行的精确重新排序。我们无法调查编译器，因此无法断定哪个编译器（通过哪个代码生成选项）可能生成易受攻击的代码。GCC 文档明确指出可以进行重新排序。如果 CPU 能够重新排序内存访问，Arm 系统也将容易受到攻击。请咨询 CPU 供应商。x86 系统仅在编译器执行重新排序时易受攻击。(CVE-2020-25603)

  - 在 4.14.x 及之前的 Xen 中发现一个问题。在 x86 HVM vCPU 之间迁移计时器时存在争用条件。当在 x86 HVM 客户机的 vCPU 之间迁移计时器时，所使用的锁定模型允许也在计时器上运行的相同客户机的第二个 vCPU 释放其未获取的锁定。此问题最可能造成的影响是虚拟机监控程序挂起或崩溃，即拒绝服务 (DoS)。所有 Xen 版本都会受到影响。只有 x86 系统易受影响。Arm 系统不易受影响。只有 x86 HVM 客户机才能利用此漏洞。x86 PV 和 PVH 无法利用此漏洞。只有具有多个 vCPU 的客户机才能利用此漏洞。(CVE-2020-25604)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
141836	Xen 迁移定时器争用条件 DoS (XSA-336)	Nessus	Misc.	2020/10/23	2020/11/13	medium
150180	OracleVM 3.4：xen (OVMSA-2021-0014)	Nessus	OracleVM Local Security Checks	2021/6/3	2022/5/9	high
141138	Debian DSA-4769-1：xen - 安全更新	Nessus	Debian Local Security Checks	2020/10/5	2024/2/16	high
165248	Ubuntu 20.04 LTS：Xen 漏洞 (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2024/8/28	high

检测

插件搜索

medium

high

high

high