According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by an issue allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions that require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.

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

incorrect error handling in event channel port allocation leads to DoS [XSA-317, CVE-2020-15566] (#1854465) inverted code paths in x86 dirty VRAM tracking leads to DoS [XSA-319, CVE-2020-15563] (#1854463) xen:
insufficient cache write-back under VT-d leads to DoS [XSA-321, CVE-2020-15565] (#1854467) missing alignment check in VCPUOP_register_vcpu_info leads to DoS [XSA-327, CVE-2020-15564] (#1854458) non-atomic modification of live EPT PTE leads to DoS [XSA-328, CVE-2020-15567] (#1854464)

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

DoSにつながるイベントチャネルポート割り当てでの不適切なエラー処理[XSA-317、CVE-2020-15566]（#1854465）x86ダーティVRAM追跡の反転コードパスがDoSにつながります[XSA-319、CVE-2020-15563]（#1854463）xen：
VT-dでの不十分なキャッシュの書き戻しは、DoSにつながります[XSA-321、CVE-2020-15565]（#1854467）VCPUOP_register_vcpu_infoのアライメントチェックの欠落により、DoSが発生します[XSA-327、CVE-2020-15564]（#1854458）ライブEPT PTEの非アトミック変更DoSにつながります[XSA-328、CVE-2020-15567]（#1854464）

注意：Tenable Network Securityは、前述の記述ブロックをFedora更新システムのWebサイトから直接抽出しています。
Tenableでは、新たな問題を持ち込まずに、できる限り自動的に整理して書式設定するようにしています。

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

自己報告されたバージョン番号によると、リモートホストにインストールされているXenハイパーバイザーは、VCPUOP_register_vcpu_infoの配置チェックがないため、ArmゲストOSユーザーがハイパーバイザクラッシュを引き起こす可能性のある問題の影響を受けます。ハイパーコールVCPUOP_register_vcpu_infoは、共有領域をハイパーバイザーに登録するためにゲストによって使用されます。領域はXenアドレス空間にマッピングされるため、直接アクセスできます。Armでは、特定のアライメントを必要とする命令で領域にアクセスします。残念ながら、ゲストが提供したアドレスが正しく整列されるかどうかのチェックはありません。その結果、悪意のあるゲストが、不整合なアドレスを渡すことでハイパーバイザーのクラッシュを引き起こす可能性があります。悪意のあるゲスト管理者がハイパーバイザーをクラッシュさせ、サービス拒否（DoS）を引き起こす可能性があります。Xenの全バージョンが脆弱です。Armシステムのみが脆弱です。x86システムは影響を受けません。

Nessusはこの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

根據其自我報告的版本號碼判斷，遠端主機上安裝的 Xen Hypervisor 受到一個問題影響，其允許 Arm 客體 OS 使用者造成 Hypervisor 當機，這是由於 VCPUOP_register_vcpu_info 中缺失對齊檢查所導致。客體使用 Hypercall VCPUOP_register_vcpu_info 在 Hypervisor 中註冊共用區域。該區域將會對應至 Xen 位址空間，因此可以直接存取。在 Arm 上，要使用需要特殊對齊的指示來存取此區域。但遺憾的是，系統無法檢查客體所提供的位址是否會正確對齊。因此，惡意客體可透過傳遞不相符的位址，造成 Hypervisor 損毀。惡意客體系統管理員可造成 Xen 當機，進而導致拒絕服務 (DoS)。所有 Xen 版本都容易受到影響。只有 Arm 系統會受到影響。x86 系統不受影響。

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

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

Xenハイパーバイザーに複数の脆弱性が発見されました。これは、サービス拒否攻撃、ゲストからホストへの権限昇格、または情報漏洩につながる可能性があります。

Multiple vulnerabilities have been discovered in the Xen hypervisor, which could result in denial of service, guest-to-host privilege escalation or information leaks.

The remote host is affected by the vulnerability described in GLSA-202007-02 (Xen: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in Xen. Please review the       CVE identifiers referenced below for details.
  Impact :

    Please review the referenced CVE identifiers for details.
  Workaround :

    There is no known workaround at this time.

根据其自我报告的版本号，远程主机上安装的 Xen 虚拟机监控程序受到一个问题影响，该问题允许 Arm 客户机操作系统用户造成虚拟机监控程序崩溃，这是因为 VCPUOP_register_vcpu_info 中缺少对齐检查所导致。客户机使用超级调用 VCPUOP_register_vcpu_info 在虚拟机监控程序中注册共享区域。该区域将被映射到 Xen 地址空间，因此可以直接访问。在 Arm 上，使用需要特定对齐的指令访问区域。但遗憾的是，未检查客户机提供的地址是否正确对齐。因此，恶意客户机可通过传递未对齐的地址造成监控程序崩溃。恶意客户机管理员可造成虚拟机监控程序崩溃，进而导致拒绝服务 (DoS)。所有 Xen 版本都容易受到攻击。只有 Arm 系统易受攻击。x86 系统不受影响。

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

远程 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
149066	Xen Missing Alignment Check DoS (XSA-327)	Nessus	Misc.	2021/4/29	2021/4/30	medium
138535	Fedora 32 : xen (2020-fbc13516af)	Nessus	Fedora Local Security Checks	2020/7/16	2024/3/1	high
138535	Fedora 32：xen（2020-fbc13516af）	Nessus	Fedora Local Security Checks	2020/7/16	2024/3/1	high
138864	Fedora 31 : xen (2020-76cf2b0f0a)	Nessus	Fedora Local Security Checks	2020/7/23	2024/2/29	high
138394	Debian DSA-4723-1：xen - 安全更新	Nessus	Debian Local Security Checks	2020/7/14	2024/3/1	high
149066	Xenの配置チェックがないDoS（XSA-327）	Nessus	Misc.	2021/4/29	2021/4/30	medium
149066	Xen 缺少對齊檢查 DoS (XSA-327)	Nessus	Misc.	2021/4/29	2021/4/30	medium
138394	Debian DSA-4723-1：xen - 安全性更新	Nessus	Debian Local Security Checks	2020/7/14	2024/3/1	high
138394	Debian DSA-4723-1: xen - セキュリティ更新	Nessus	Debian Local Security Checks	2020/7/14	2024/3/1	high
138864	Fedora 31：xen（2020-76cf2b0f0a）	Nessus	Fedora Local Security Checks	2020/7/23	2024/2/29	high
138394	Debian DSA-4723-1 : xen - security update	Nessus	Debian Local Security Checks	2020/7/14	2024/3/1	high
138925	GLSA-202007-02 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	2020/7/27	2024/2/28	high
149066	Xen 缺少对齐检查 DoS (XSA-327)	Nessus	Misc.	2021/4/29	2021/4/30	medium
165248	Ubuntu 20.04 LTS : Xen vulnerabilities (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2023/7/12	high
165248	Ubuntu 20.04LTS: Xen の脆弱性 (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2023/7/12	high
165248	Ubuntu 20.04 LTS：Xen 漏洞 (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2023/7/12	high
165248	Ubuntu 20.04 LTS：Xen 弱點 (USN-5617-1)	Nessus	Ubuntu Local Security Checks	2022/9/19	2023/7/12	high

偵測

搜尋 Plugin

medium

high

high

high

high

medium

medium

high

high

high

high

high

medium

high

high

high

high