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

  - 在取消分配（第二次）客户机获得对某些 Xen 拥有的内存页面的访问权限后，授予表 v2 状态页面仍可访问。大多数此类页面在其整个生命周期内都会保持与客户机的分配/关联关系。但是，当客户机从 v2 切换（返回）到 v1 时，授予表 v2 状态页会被取消分配。释放这些页面需要管理程序知道这些页面在客户机中的具体映射位置。管理程序仅跟踪客户机空间中的一个使用，但客户机要求插入这些页面的映射的争用请求可能导致其中任何一个页面被映射到多个位置。从 v2 切换回 v1 时，客户机将保留对已释放页面的访问权限，并可能将其重新用于其他目的。此缺陷偶然已通过清理 Xen 4.14 中的代码修复，并且作为修复 XSA-378 的先决条件向后移植至安全支持的 Xen 分支。(CVE-2021-28703)

  - 对未对齐的 GFN 执行 PoD 操作 [此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] x86 HVM 和 PVH 客户机上，可以 populate-on-demand (PoD) 模式启动 PoD 操作，以便为以后轻松分配更多内存提供方法。允许访客通过超级调用控制单个页面的某些 P2M 方面。这些超级调用可作用于通过页面顺序指定的页面范围（导致页面的幂次方）。PoD 的其中一些超级调用的实现未强制执行针对指定顺序适当对齐的基本页面框架编号，但 PoD 处理中涉及的某些代码实际上会做出此类假设。这些操作指 XENMEM_decrease_reservation (CVE-2021-28704) 和 XENMEM_populate_physmap (CVE-2021-28707)，后者仅可由控制客户机的域（即取消权限的 qemu 或 stub 域）使用。
    （修补程序 1，合并了对这两个问题的补丁。）此外，当指定的页面顺序既不是 4k 也不是 2M 也不是 1G 时，处理 XENMEM_decrease_reservation 也会触发主机崩溃（CVE-2021-28708，修补程序 2）。 (CVE-2021-28704、CVE-2021-28707、CVE-2021-28708)

  - x86 T 上部分成功的 P2M 更新问题[他的 CNA 信息记录与多个 CVE 有关；
    文本说明了哪些方面/漏洞对应于哪些 CVE。] x86 HVM 和 PVH 客户机上，可以 populate-on-demand (PoD) 模式启动 PoD 操作，以便为以后轻松分配更多内存提供方法。允许访客通过超级调用控制单个页面的某些 P2M 方面。这些超级调用可作用于通过页面顺序指定的页面范围（导致页面的幂次方）。在某些情况下，管理程序通过将请求拆分为更小的块来执行请求。某些 PoD 情况下的错误处理不充分，特别是未正确考虑某些操作未完全成功执行的情况。有两个受影响的代码路径：页面删除 (CVE-2021-28705) 和新页面的插入 (CVE-2021-28709)。（我们提供一个修补程序，结合了这两个问题的补丁。）(CVE-2021-28705, CVE-2021-28709)

  - 来宾机可能超出其指定的内存限制当来宾机获准使用接近 16TiB 的内存时，它可能会发出超级调用以将其内存分配增加到管理员建立的限制之外。这是以 32 位精度完成的计算结果，有可能会发生溢出。但之后只会将溢出的数字（因此很小）与已建立的上限进行比较。(CVE-2021-28706)

  - 拒绝原因：请勿使用此候选编号。ConsultIDs：无。原因：其 CNA 未使用此候选编号。注意：无。(CVE-2022-23816)

  - IBPB 可能无法防止 pre-IBPB 分支目标指定返回分支预测，从而会导致潜在的信息泄露。(CVE-2022-23824)

  - 分支预测器中的别名可能导致某些 AMD 处理器预测错误的分支类型，从而可能导致信息泄露。(CVE-2022-23825)

  - 脏 vram 跟踪和分页脏日志超级调用之间交互活跃。XEN_DMOP_track_dirty_vram（Xen 4.9 之前版本中称为 HVMOP_track_dirty_vram）在激活脏日志模式时，正在进行的脏日志超级调用非常活跃。当另一个 CPU 仍在拆除与之前启用的脏日志模式 (XEN_DOMCTL_SHADOW_OP_OFF) 相关的结构时，对 XEN_DMOP_track_dirty_vram 的适当定时调用可启用脏日志。这是由于两项操作之间缺少互斥锁定，从而导致在已释放的插槽中添加条目，并造成内存泄漏。
    (CVE-2022-26356)

  - VT-d 域 ID 清除中的争用 Xen 域 ID 宽度上限为 15 位。VT-d 硬件可能只允许使用少于 15 位的宽度保留将物理设备与特定域相关联的域 ID。因此，Xen 域 ID 会在内部被映射到较小的值范围。内务结构清理进程存在争用，从而允许泄露 VT-d 域 ID 并绕过刷新。
    (CVE-2022-26357)

  - IOMMU：RMRR (VT-d) 和 unity map (AMD-Vi) 处理问题 [此 CNA 信息记录与多个 CVE 相关；且正文说明了哪些方面/漏洞对应于哪些 CVE。] 系统中的某些 PCI 设备可能会被分配用于 Intel VT-d 或用于 AMD-Vi 的 Unity 映射范围的预留内存区域（通过“预留内存区域报告 (RMRR)”指定）。这些设备通常用于执行平台任务，例如旧版 USB 仿真。由于这些区域的确切用途未知，与此类区域相关联的设备一旦激活后，这些区域的映射需要仍然可供该设备持续访问。已违反此要求。来自设备的后续 DMA 或中断可能表现不可预测的行为，范围从 IOMMU 错误到内存损坏。（CVE-2022-26358、CVE-2022-26359、CVE-2022-26360、CVE-2022-26361）

  - 启用 SMT 后，某些 AMD 处理器可能在 SMT 模式切换后使用同级线程中的目标来推测性地执行指令，从而导致信息泄露。(CVE-2022-27672)

  - 在某些与微架构相关的条件下，错误训练的返回指令分支预测可能允许任意推测代码执行。(CVE-2022-29900)

  - 第 6 至 8 代 Intel 微处理器受到一个新 Spectre 变体的影响，它能够绕过内核中的 retpoline 缓解措施，泄漏任意数据。具有非特权用户访问权限的攻击者可劫持返回指令，从而在特定的微架构相关条件下执行任意推测代码。(CVE-2022-29901)

  - P2M 池释放可能耗时过长。支持客户机的二级地址转换的 P2M 池可能很大。因此，在没有中间抢占检查的情况下，其释放时间可能超过所需的合理时间。到目前为止，还缺少对抢占必要性的检查。(CVE-2022-33746)

  - Arm：二级页面表的无限内存消耗。例如，某些操作需要从客户机的 P2M（物理到机器）映射中删除页面。当使用大型页面映射第二阶段页面表中的来宾页面时，此类删除操作可能会导致内存分配（以单个较小的映射替换大型映射）。这些内存分配取自全局内存池。恶意客户机可能会通过操纵自己的 P2M 映射，造成全局内存池耗尽。
    (CVE-2022-33747)

  - 可传递授权副本处理中的锁定顺序反转。作为 XSA-226 的一部分，在错误处理路径中插入了缺失的清理调用。这样做时，未注意锁定要求。因此，相互授予可传递授权的两个合作客户机可导致获取彼此嵌套的锁定，但顺序分别相反。如果在所涉及的授权复制操作之间时机合适，这可能导致 CPU 锁定。(CVE-2022-33748)

  - XAPI 开放文件限制 DoS 网络上未经身份验证的客户端可能造成 XAPI 达到其文件描述符限制。这造成 XAPI 无法接受其他（受信任）客户端的新请求，并阻止 XAPI 执行任何需要打开文件描述符的任务。
    (CVE-2022-33749)

  - Xenstore：客户机可造成 xenstored 崩溃。由于 XSA-115 补丁中有一个缺陷，恶意客户机在错误路径中创建节点期间可造成 xenstored 使用错误的指针，导致 xenstored 崩溃或 xenstored 中的内存损坏，从而造成进一步的损坏。客户机可通过超出每个域的最大节点配额值来控制进入错误路径。(CVE-2022-42309)

  - Xenstore：客户机可创建孤立的 Xenstore 节点。通过在导致错误的事务内创建多个节点，恶意客户机可在 Xenstore 数据库中创建孤立的节点，这是因为发生错误后的清理不会删除所有已创建的节点。在此情况之后提交事务时，可将没有有效父项的节点固定于数据库中。(CVE-2022-42310)

  - Xenstore：客户机可造成 Xenstore 不释放临时内存。处理客户机请求时，xenstored 可能需要临时分配大量内存。仅在请求完全完成后才会释放此内存。只有在客户机从环页读取请求的响应消息后，才认为请求已完成。因此，客户机若不读取响应，可导致 xenstored 不会释放临时内存。这可造成内存不足，从而引致 xenstored 拒绝服务 (DoS)。(CVE-2022-42319)

  - Xenstore：客户机可获得对已删除域的 Xenstore 节点的访问权限。Xenstore 节点的访问权限基于 domid。域删除后，可能剩下具有访问权限的 Xenstore 节点，其中包含已删除域的 domid。这通常没有问题，因为稍后写入此类节点时将更正这些访问权限条目。创建新域时存在一个小的时间窗口，期间与新域具有相同 domid 的旧域的访问权限仍被视为有效，这导致新域能够访问原本应由被删除的域访问的节点。发生此情况的前提是，在 dom0 将新创建的域引入 Xenstore 之前，另一个域需要写入该节点。(CVE-2022-42320)

  - Xenstore：客户机可通过耗尽堆栈造成 Xenstored 崩溃。Xenstored 对某些 Xenstore 操作（例如，删除 Xenstore 节点的子树）使用递归。通过足够深的嵌套级别，这可导致 xenstored 上的堆栈耗尽，从而造成 xenstored 崩溃。(CVE-2022-42321)

  - Xenstore：合作的客户机可创建任意数量的节点 [此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 修复 XSA-322 后，由删除的域拥有的所有 Xenstore 节点都将被修改为 Dom0。这允许两个恶意客户机共同创建任意数量的 Xenstore 节点。可能的做法是：域 A 允许域 B 写入到域 A 的本地 Xenstore 树，然后，域 B 可以创建许多节点并重新启动。域 B 创建的节点现在由 Dom0 所拥有。因为 Dom0 的节点数量不受 Xenstore 配额的限制，所以通过不断地重复此过程，可以创建任意数量的节点。(CVE-2022-42322、CVE-2022-42323)

  - Oxenstored 32->31 位整数截断问题。Ocaml 中的整数为有正负号的 63 位或 31 位精度。
    Ocaml Xenbus 库从环中提取 C uint32_t，并将其直接转换为 Ocaml 整数。在 64 位 Ocaml 版本中，这没有问题，但在 32 位版本中，它会截断最高有效位，然后在余数中造成无正负号/有正负号混淆。这反过来又可以将负值馈送至预期为非负值的逻辑中，从而导致系统抛出意外异常。由于未正确处理意外异常，造成尝试从 xenstore 环中取出错误数据包（但失败）的忙循环。(CVE-2022-42324)

  - Xenstore：客户机可通过事务创建任意数量的节点 [此 CNA 信息记录与多个 CVE 相关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 如果已在事务中创建节点，而后在同一事务中将其删除，该事务将因错误而终止。仅在事务完成时处理已删除的节点时才会遇到此错误，因此系统将在不更新记账信息的情况下部分执行事务。这将使恶意客户机能够创建任意数量的节点。
    （CVE-2022-42325、CVE-2022-42326）

  - x86: 在支持虚拟化 APIC 访问功能的 Intel 系统上发生客户机之间意外共享内存，客户机可将本地 APIC 移出 xAPIC 模式，以读取和写入全局共享的 xAPIC 页面。访问此共享页面会绕过两个客户机之间应存在的预期隔离机制。
    (CVE-2022-42327)

  - 客户机可通过软重置造成 Xenstore 崩溃 当客户机发出软重置（例如，为了执行 kexec）命令时，基于 libxl 的 Xen 工具堆栈通常会执行 XS_RELEASE Xenstore 操作。xenstored 中存在的缺陷会导致 xenstored 崩溃。任何其他使用 XS_RELEASE 的情形都将受到相同的影响。(CVE-2022-42330)

  - x86: 32 位 SYSCALL 路径中的推测漏洞 由于最初的 Spectre/Meltdown 安全工作 (XSA-254) 中的一个疏忽，一个 entrypath 执行其推测安全操作为时过晚。
    在某些配置中，存在不受保护的 RET 指令，其可受到多种推测攻击。(CVE-2022-42331)

  - x86 影子加日志脏模式释放后使用 在需要主机协助地址转换但硬件协助分页 (HAP) 不可用的环境中，Xen 将以所谓的影子模式运行客户机。
    影子模式维护一个用于影子页表和辅助数据结构的内存池。为了迁移客户机或为其创建快照，Xen 还以所谓的脏日志模式运行它们。脏日志跟踪所需的数据结构是上述辅助数据的一部分。为了将错误处理工作保持在合理的范围内，对于可能需要内存分配的操作，影子模式逻辑预先确保有足够的内存用于最坏情况。
    遗憾的是，虽然在需要可能建立新影子的代码路径上正确考虑了页表内存，但未考虑脏日志基础架构的需求。因此，刚建立的影子页表可立即被再次释放，而其他代码仍假设它们将保持已分配状态。(CVE-2022-42332)

  - x86/HVM 固定缓存属性错误处理 [此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 为了允许对具有直通设备的 HVM 来宾进行可缓存性控制，存在一个接口来显式覆盖默认值，否则这些默认值将被放置到位。尽管未向受影响的来宾机本身公开，但该接口专门用于控制此类来宾机。因此，此接口可能会被非完全权限的实体使用，例如在 Dom0 中运行 deprivileged 的 qemu 或在所谓的 stub-domain 中运行的 qemu。由于此次暴露，存在一个问题：此类受控区域的数量不受限制 (CVE-2022-42333)；此类区域的安装和删除未正确序列化 (CVE-2022-42334)。（CVE-2022-42333、CVE-2022-42334）

  - x86 影子分页任意指针取消引用 在需要主机协助地址转换但硬件协助分页 (HAP) 不可用的环境中，Xen 将以所谓的影子模式运行客户机。
    由于对用于阴影页面处理的某个管理程序例程的检查过于宽松，通过 PCI 设备传递的客户机可能会导致管理程序访问部分被客户机控制的任意指针。(CVE-2022-42335)

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

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

  - 影子模式下 x86 PV 客户机的 TLB 刷新不充分。在未发现 L1TF 的情况下，为了迁移以及排除内核故障（请参阅 XSA-273），PV 客户机可能在影子分页模式下运行。为解决 XSA-401，已移动 Xen 中函数内部的代码。此代码移动缺少在新旧代码位置之间更改含义/值的变量。现在错误地使用该变量会导致错误的 TLB 刷新条件，从而忽略必要的刷新。(CVE-2022-33745)

  - P2M 池释放可能耗时过长。支持客户机的二级地址转换的 P2M 池可能很大。因此，在没有中间抢占检查的情况下，其释放时间可能超过所需的合理时间。到目前为止，还缺少对抢占必要性的检查。(CVE-2022-33746)

  - Arm：二级页面表的无限内存消耗。例如，某些操作需要从客户机的 P2M（物理到机器）映射中删除页面。当使用大型页面映射第二阶段页面表中的来宾页面时，此类删除操作可能会导致内存分配（以单个较小的映射替换大型映射）。这些内存分配取自全局内存池。恶意客户机可能会通过操纵自己的 P2M 映射，造成全局内存池耗尽。
    (CVE-2022-33747)

  - 可传递授权副本处理中的锁定顺序反转。作为 XSA-226 的一部分，在错误处理路径中插入了缺失的清理调用。这样做时，未注意锁定要求。因此，相互授予可传递授权的两个合作客户机可导致获取彼此嵌套的锁定，但顺序分别相反。如果在所涉及的授权复制操作之间时机合适，这可能导致 CPU 锁定。(CVE-2022-33748)

  - Xenstore：客户机可造成 xenstored 崩溃。由于 XSA-115 补丁中有一个缺陷，恶意客户机在错误路径中创建节点期间可造成 xenstored 使用错误的指针，导致 xenstored 崩溃或 xenstored 中的内存损坏，从而造成进一步的损坏。客户机可通过超出每个域的最大节点配额值来控制进入错误路径。(CVE-2022-42309)

  - Xenstore：客户机可创建孤立的 Xenstore 节点。通过在导致错误的事务内创建多个节点，恶意客户机可在 Xenstore 数据库中创建孤立的节点，这是因为发生错误后的清理不会删除所有已创建的节点。在此情况之后提交事务时，可将没有有效父项的节点固定于数据库中。(CVE-2022-42310)

  - Xenstore：客户机允许 xenstore 运行时发生内存不足。[此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 恶意客户机可造成 xenstored 分配大量内存，最终导致 xenstored 拒绝服务 (DoS)。客户机可通过多种方式在 xenstored 中造成大量内存分配：- - 向 xenstored 发出新请求而不读取响应，导致系统在内存中缓冲这些响应 - - 通过设置多个 xenstore Watch，然后删除监视路径下的许多 xenstore 节点，导致生成大量 Watch 事件 - - 通过在尽可能多的事务中以允许的最大大小和路径长度创建尽可能多的节点 - 通过访问事务内的多个节点（CVE-2022-42311、CVE-2022-42312、CVE-2022-42313、CVE-2022-42314、CVE-2022-42315、CVE-2022-42316、CVE-2022-42317、CVE-2022-42318)

  - Xenstore：客户机可造成 Xenstore 不释放临时内存。处理客户机请求时，xenstored 可能需要临时分配大量内存。仅在请求完全完成后才会释放此内存。只有在客户机从环页读取请求的响应消息后，才认为请求已完成。因此，客户机若不读取响应，可导致 xenstored 不会释放临时内存。这可造成内存不足，从而引致 xenstored 拒绝服务 (DoS)。(CVE-2022-42319)

  - Xenstore：客户机可获得对已删除域的 Xenstore 节点的访问权限。Xenstore 节点的访问权限基于 domid。域删除后，可能剩下具有访问权限的 Xenstore 节点，其中包含已删除域的 domid。这通常没有问题，因为稍后写入此类节点时将更正这些访问权限条目。创建新域时存在一个小的时间窗口，期间与新域具有相同 domid 的旧域的访问权限仍被视为有效，这导致新域能够访问原本应由被删除的域访问的节点。发生此情况的前提是，在 dom0 将新创建的域引入 Xenstore 之前，另一个域需要写入该节点。(CVE-2022-42320)

  - Xenstore：客户机可通过耗尽堆栈造成 Xenstored 崩溃。Xenstored 对某些 Xenstore 操作（例如，删除 Xenstore 节点的子树）使用递归。通过足够深的嵌套级别，这可导致 xenstored 上的堆栈耗尽，从而造成 xenstored 崩溃。(CVE-2022-42321)

  - Xenstore：合作的客户机可创建任意数量的节点 [此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 修复 XSA-322 后，由删除的域拥有的所有 Xenstore 节点都将被修改为 Dom0。这允许两个恶意客户机共同创建任意数量的 Xenstore 节点。可能的做法是：域 A 允许域 B 写入到域 A 的本地 Xenstore 树，然后，域 B 可以创建许多节点并重新启动。域 B 创建的节点现在由 Dom0 所拥有。因为 Dom0 的节点数量不受 Xenstore 配额的限制，所以通过不断地重复此过程，可以创建任意数量的节点。(CVE-2022-42322、CVE-2022-42323)

  - Oxenstored 32->31 位整数截断问题。Ocaml 中的整数为有正负号的 63 位或 31 位精度。
    Ocaml Xenbus 库从环中提取 C uint32_t，并将其直接转换为 Ocaml 整数。在 64 位 Ocaml 版本中，这没有问题，但在 32 位版本中，它会截断最高有效位，然后在余数中造成无正负号/有正负号混淆。这反过来又可以将负值馈送至预期为非负值的逻辑中，从而导致系统抛出意外异常。由于未正确处理意外异常，造成尝试从 xenstore 环中取出错误数据包（但失败）的忙循环。(CVE-2022-42324)

  - Xenstore：客户机可通过事务创建任意数量的节点 [此 CNA 信息记录与多个 CVE 相关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 如果已在事务中创建节点，而后在同一事务中将其删除，该事务将因错误而终止。仅在事务完成时处理已删除的节点时才会遇到此错误，因此系统将在不更新记账信息的情况下部分执行事务。这将使恶意客户机能够创建任意数量的节点。
    (CVE-2022-42325, CVE-2022-42326)

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

根据其自我报告的版本号，远程主机上安装的 Xen hypervisor 受到其节点创建功能中的一个漏洞影响。如果已在一个事务中创建节点，然后在同一事务中将其删除，该事务将因错误而终止。仅在事务完成时处理已删除的节点时才会遇到此错误，因此系统将在不更新记账信息的情况下部分执行事务。这将使恶意客户机能够创建任意数量的节点。

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

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

  - Xenstore：客户机可造成 xenstored 崩溃。由于 XSA-115 补丁中有一个缺陷，恶意客户机在错误路径中创建节点期间可造成 xenstored 使用错误的指针，导致 xenstored 崩溃或 xenstored 中的内存损坏，从而造成进一步的损坏。客户机可通过超出每个域的最大节点配额值来控制进入错误路径。(CVE-2022-42309)

  - Xenstore：客户机可创建孤立的 Xenstore 节点。通过在导致错误的事务内创建多个节点，恶意客户机可在 Xenstore 数据库中创建孤立的节点，这是因为发生错误后的清理不会删除所有已创建的节点。在此情况之后提交事务时，可将没有有效父项的节点固定于数据库中。(CVE-2022-42310)

  - Xenstore：客户机允许 xenstore 运行时发生内存不足。[此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 恶意客户机可造成 xenstored 分配大量内存，最终导致 xenstored 拒绝服务 (DoS)。客户机可通过多种方式在 xenstored 中造成大量内存分配：- - 向 xenstored 发出新请求而不读取响应，导致系统在内存中缓冲这些响应 - - 通过设置多个 xenstore Watch，然后删除监视路径下的许多 xenstore 节点，导致生成大量 Watch 事件 - - 通过在尽可能多的事务中以允许的最大大小和路径长度创建尽可能多的节点 - 通过访问事务内的多个节点（CVE-2022-42311、CVE-2022-42312、CVE-2022-42313、CVE-2022-42314、CVE-2022-42315、CVE-2022-42316、CVE-2022-42317、CVE-2022-42318)

  - Xenstore：客户机可造成 Xenstore 不释放临时内存。处理客户机请求时，xenstored 可能需要临时分配大量内存。仅在请求完全完成后才会释放此内存。只有在客户机从环页读取请求的响应消息后，才认为请求已完成。因此，客户机若不读取响应，可导致 xenstored 不会释放临时内存。这可造成内存不足，从而引致 xenstored 拒绝服务 (DoS)。(CVE-2022-42319)

  - Xenstore：客户机可获得对已删除域的 Xenstore 节点的访问权限。Xenstore 节点的访问权限基于 domid。域删除后，可能剩下具有访问权限的 Xenstore 节点，其中包含已删除域的 domid。这通常没有问题，因为稍后写入此类节点时将更正这些访问权限条目。创建新域时存在一个小的时间窗口，期间与新域具有相同 domid 的旧域的访问权限仍被视为有效，这导致新域能够访问原本应由被删除的域访问的节点。发生此情况的前提是，在 dom0 将新创建的域引入 Xenstore 之前，另一个域需要写入该节点。(CVE-2022-42320)

  - Xenstore：客户机可通过耗尽堆栈造成 Xenstored 崩溃。Xenstored 对某些 Xenstore 操作（例如，删除 Xenstore 节点的子树）使用递归。通过足够深的嵌套级别，这可导致 xenstored 上的堆栈耗尽，从而造成 xenstored 崩溃。(CVE-2022-42321)

  - Xenstore：合作的客户机可创建任意数量的节点 [此 CNA 信息记录与多个 CVE 有关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 修复 XSA-322 后，由删除的域拥有的所有 Xenstore 节点都将被修改为 Dom0。这允许两个恶意客户机共同创建任意数量的 Xenstore 节点。可能的做法是：域 A 允许域 B 写入到域 A 的本地 Xenstore 树，然后，域 B 可以创建许多节点并重新启动。域 B 创建的节点现在由 Dom0 所拥有。因为 Dom0 的节点数量不受 Xenstore 配额的限制，所以通过不断地重复此过程，可以创建任意数量的节点。(CVE-2022-42322、CVE-2022-42323)

  - Xenstore：客户机可通过事务创建任意数量的节点 [此 CNA 信息记录与多个 CVE 相关；文本说明了哪些方面/漏洞对应于哪些 CVE。] 如果已在事务中创建节点，而后在同一事务中将其删除，该事务将因错误而终止。仅在事务完成时处理已删除的节点时才会遇到此错误，因此系统将在不更新记账信息的情况下部分执行事务。这将使恶意客户机能够创建任意数量的节点。
    （CVE-2022-42325、CVE-2022-42326）

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
189976	GLSA-202402-07：Xen：多个漏洞	Nessus	Gentoo Local Security Checks	2024/2/4	2024/2/4	high
167052	Debian DSA-5272-1：xen - 安全更新	Nessus	Debian Local Security Checks	2022/11/7	2023/10/25	high
167248	Xenstore：客户机可通过事务创建任意数量的节点 (XSA-421)	Nessus	Misc.	2022/11/10	2023/10/25	medium
173270	OracleVM 3.4：xen (OVMSA-2023-0005)	Nessus	OracleVM Local Security Checks	2023/3/22	2023/9/8	high

检测

插件搜索

high

high

medium

high