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

  - grant table v2 status pages may remain accessible after de-allocation (take two) 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. This bug was fortuitously fixed by code cleanup in Xen 4.14, and     backported to security-supported Xen branches as a prerequisite of the fix for XSA-378. (CVE-2021-28703)

  - PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains     which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-     on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are     permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on     ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation     of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for     the specified order, yet some code involved in PoD handling actually makes such an assumption. These     operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707),     the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain.
    (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation     can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708,     patch 2). (CVE-2021-28704, CVE-2021-28707, CVE-2021-28708)

  - issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs;
    the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be     started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory     assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These     hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of     pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error     handling in certain PoD cases has been insufficient in that in particular partial success of some     operations was not properly accounted for. There are two code paths affected - page removal     (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix     to both issues.) (CVE-2021-28705, CVE-2021-28709)

  - guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of     memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator     established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It     would then only be the overflowed (and hence small) number which gets compared against the established     upper bound. (CVE-2021-28706)

  - Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate is unused by     its CNA. Notes: none. (CVE-2022-23816)

  - IBPB may not prevent return branch predictions from being specified by pre-IBPB branch targets leading to     a potential information disclosure. (CVE-2022-23824)

  - Aliases in the branch predictor may cause some AMD processors to predict the wrong branch type potentially     leading to information disclosure. (CVE-2022-23825)

  - Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode     done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing     log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while     another CPU is still in the process of tearing down the structures related to a previously enabled log     dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both     operations and can lead to entries being added in already freed slots, resulting in a memory leak.
    (CVE-2022-26356)

  - race in VT-d domain ID cleanup Xen domain IDs are up to 15 bits wide. VT-d hardware may allow for only     less than 15 bits to hold a domain ID associating a physical device with a particular domain. Therefore     internally Xen domain IDs are mapped to the smaller value range. The cleaning up of the housekeeping     structures has a race, allowing for VT-d domain IDs to be leaked and flushes to be bypassed.
    (CVE-2022-26357)

  - IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues T[his CNA information record relates to multiple     CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Certain PCI devices in a     system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, RMRR)     for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as     legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with     such a region is active, the mappings of these regions need to remain continuouly accessible by the     device. This requirement has been violated. Subsequent DMA or interrupts from the device may have     unpredictable behaviour, ranging from IOMMU faults to memory corruption. (CVE-2022-26358, CVE-2022-26359,     CVE-2022-26360, CVE-2022-26361)

  - When SMT is enabled, certain AMD processors may speculatively execute instructions using a target from the     sibling thread after an SMT mode switch potentially resulting in information disclosure. (CVE-2022-27672)

  - Mis-trained branch predictions for return instructions may allow arbitrary speculative code execution     under certain microarchitecture-dependent conditions. (CVE-2022-29900)

  - Intel microprocessor generations 6 to 8 are affected by a new Spectre variant that is able to bypass their     retpoline mitigation in the kernel to leak arbitrary data. An attacker with unprivileged user access can     hijack return instructions to achieve arbitrary speculative code execution under certain     microarchitecture-dependent conditions. (CVE-2022-29901)

  - P2M pool freeing may take excessively long The P2M pool backing second level address translation for     guests may be of significant size. Therefore its freeing may take more time than is reasonable without     intermediate preemption checks. Such checking for the need to preempt was so far missing. (CVE-2022-33746)

  - Arm: unbounded memory consumption for 2nd-level page tables Certain actions require e.g. removing pages     from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the     2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping     with individual smaller ones). These memory allocations are taken from the global memory pool. A malicious     guest might be able to cause the global memory pool to be exhausted by manipulating its own P2M mappings.
    (CVE-2022-33747)

  - lock order inversion in transitive grant copy handling As part of XSA-226 a missing cleanup call was     inserted on an error handling path. While doing so, locking requirements were not paid attention to. As a     result two cooperating guests granting each other transitive grants can cause locks to be acquired nested     within one another, but in respectively opposite order. With suitable timing between the involved grant     copy operations this may result in the locking up of a CPU. (CVE-2022-33748)

  - XAPI open file limit DoS It is possible for an unauthenticated client on the network to cause XAPI to hit     its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted)     clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors.
    (CVE-2022-33749)

  - Xenstore: Guests can crash xenstored Due to a bug in the fix of XSA-115 a malicious guest can cause     xenstored to use a wrong pointer during node creation in an error path, resulting in a crash of xenstored     or a memory corruption in xenstored causing further damage. Entering the error path can be controlled by     the guest e.g. by exceeding the quota value of maximum nodes per domain. (CVE-2022-42309)

  - Xenstore: Guests can create orphaned Xenstore nodes By creating multiple nodes inside a transaction     resulting in an error, a malicious guest can create orphaned nodes in the Xenstore data base, as the     cleanup after the error will not remove all nodes already created. When the transaction is committed after     this situation, nodes without a valid parent can be made permanent in the data base. (CVE-2022-42310)

  - Xenstore: Guests can cause Xenstore to not free temporary memory When working on a request of a guest,     xenstored might need to allocate quite large amounts of memory temporarily. This memory is freed only     after the request has been finished completely. A request is regarded to be finished only after the guest     has read the response message of the request from the ring page. Thus a guest not reading the response can     cause xenstored to not free the temporary memory. This can result in memory shortages causing Denial of     Service (DoS) of xenstored. (CVE-2022-42319)

  - Xenstore: Guests can get access to Xenstore nodes of deleted domains Access rights of Xenstore nodes are     per domid. When a domain is gone, there might be Xenstore nodes left with access rights containing the     domid of the removed domain. This is normally no problem, as those access right entries will be corrected     when such a node is written later. There is a small time window when a new domain is created, where the     access rights of a past domain with the same domid as the new one will be regarded to be still valid,     leading to the new domain being able to get access to a node which was meant to be accessible by the     removed domain. For this to happen another domain needs to write the node before the newly created domain     is being introduced to Xenstore by dom0. (CVE-2022-42320)

  - Xenstore: Guests can crash xenstored via exhausting the stack Xenstored is using recursion for some     Xenstore operations (e.g. for deleting a sub-tree of Xenstore nodes). With sufficiently deep nesting     levels this can result in stack exhaustion on xenstored, leading to a crash of xenstored. (CVE-2022-42321)

  - Xenstore: Cooperating guests can create arbitrary numbers of nodes T[his CNA information record relates to     multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Since the fix of     XSA-322 any Xenstore node owned by a removed domain will be modified to be owned by Dom0. This will allow     two malicious guests working together to create an arbitrary number of Xenstore nodes. This is possible by     domain A letting domain B write into domain A's local Xenstore tree. Domain B can then create many nodes     and reboot. The nodes created by domain B will now be owned by Dom0. By repeating this process over and     over again an arbitrary number of nodes can be created, as Dom0's number of nodes isn't limited by     Xenstore quota. (CVE-2022-42322, CVE-2022-42323)

  - Oxenstored 32->31 bit integer truncation issues Integers in Ocaml are 63 or 31 bits of signed precision.
    The Ocaml Xenbus library takes a C uint32_t out of the ring and casts it directly to an Ocaml integer. In     64-bit Ocaml builds this is fine, but in 32-bit builds, it truncates off the most significant bit, and     then creates unsigned/signed confusion in the remainder. This in turn can feed a negative value into logic     not expecting a negative value, resulting in unexpected exceptions being thrown. The unexpected exception     is not handled suitably, creating a busy-loop trying (and failing) to take the bad packet out of the     xenstore ring. (CVE-2022-42324)

  - Xenstore: Guests can create arbitrary number of nodes via transactions T[his CNA information record     relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] In     case a node has been created in a transaction and it is later deleted in the same transaction, the     transaction will be terminated with an error. As this error is encountered only when handling the deleted     node at transaction finalization, the transaction will have been performed partially and without updating     the accounting information. This will enable a malicious guest to create arbitrary number of nodes.
    (CVE-2022-42325, CVE-2022-42326)

  - x86: unintended memory sharing between guests On Intel systems that support the virtualize APIC accesses     feature, a guest can read and write the global shared xAPIC page by moving the local APIC out of xAPIC     mode. Access to this shared page bypasses the expected isolation that should exist between two guests.
    (CVE-2022-42327)

  - Guests can cause Xenstore crash via soft reset When a guest issues a Soft Reset (e.g. for performing a     kexec) the libxl based Xen toolstack will normally perform a XS_RELEASE Xenstore operation. Due to a bug     in xenstored this can result in a crash of xenstored. Any other use of XS_RELEASE will have the same     impact. (CVE-2022-42330)

  - x86: speculative vulnerability in 32bit SYSCALL path Due to an oversight in the very original     Spectre/Meltdown security work (XSA-254), one entrypath performs its speculation-safety actions too late.
    In some configurations, there is an unprotected RET instruction which can be attacked with a variety of     speculative attacks. (CVE-2022-42331)

  - x86 shadow plus log-dirty mode use-after-free In environments where host assisted address translation is     necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode.
    Shadow mode maintains a pool of memory used for both shadow page tables as well as auxiliary data     structures. To migrate or snapshot guests, Xen additionally runs them in so called log-dirty mode. The     data structures needed by the log-dirty tracking are part of aformentioned auxiliary data. In order to     keep error handling efforts within reasonable bounds, for operations which may require memory allocations     shadow mode logic ensures up front that enough memory is available for the worst case requirements.
    Unfortunately, while page table memory is properly accounted for on the code path requiring the potential     establishing of new shadows, demands by the log-dirty infrastructure were not taken into consideration. As     a result, just established shadow page tables could be freed again immediately, while other code is still     accessing them on the assumption that they would remain allocated. (CVE-2022-42332)

  - x86/HVM pinned cache attributes mis-handling T[his CNA information record relates to multiple CVEs; the     text explains which aspects/vulnerabilities correspond to which CVE.] To allow cachability control for HVM     guests with passed through devices, an interface exists to explicitly override defaults which would     otherwise be put in place. While not exposed to the affected guests themselves, the interface specifically     exists for domains controlling such guests. This interface may therefore be used by not fully privileged     entities, e.g. qemu running deprivileged in Dom0 or qemu running in a so called stub-domain. With this     exposure it is an issue that - the number of the such controlled regions was unbounded (CVE-2022-42333), -     installation and removal of such regions was not properly serialized (CVE-2022-42334). (CVE-2022-42333,     CVE-2022-42334)

  - x86 shadow paging arbitrary pointer dereference In environments where host assisted address translation is     necessary but Hardware Assisted Paging (HAP) is unavailable, Xen will run guests in so called shadow mode.
    Due to too lax a check in one of the hypervisor routines used for shadow page handling it is possible for     a guest with a PCI device passed through to cause the hypervisor to access an arbitrary pointer partially     under guest control. (CVE-2022-42335)

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

The remote SUSE Linux SLES11 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2021:14848-1 advisory.

  - Observable response discrepancy in some Intel(R) Processors may allow an authorized user to potentially     enable information disclosure via local access. (CVE-2021-0089)

  - A stack overflow via an infinite recursion vulnerability was found in the eepro100 i8255x device emulator     of QEMU. This issue occurs while processing controller commands due to a DMA reentry issue. This flaw     allows a guest user or process to consume CPU cycles or crash the QEMU process on the host, resulting in a     denial of service. The highest threat from this vulnerability is to system availability. (CVE-2021-20255)

  - x86: TSX Async Abort protections not restored after S3 This issue relates to the TSX Async Abort     speculative security vulnerability. Please see https://xenbits.xen.org/xsa/advisory-305.html for details.
    Mitigating TAA by disabling TSX (the default and preferred option) requires selecting a non-default     setting in MSR_TSX_CTRL. This setting isn't restored after S3 suspend. (CVE-2021-28690)

  - inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel     with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous     notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the     completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to     fail overly-slow commands. The course of action upon a perceived timeout actually being detected is     inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as     crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue     as if the IOMMU operation succeeded. (CVE-2021-28692)

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

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

  - grant table v2 status pages may remain accessible after de-allocation (take two) 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. This bug was fortuitously fixed by code cleanup in Xen 4.14, and     backported to security-supported Xen branches as a prerequisite of the fix for XSA-378. (CVE-2021-28703)

  - issues with partially successful P2M updates on x86 T[his CNA information record relates to multiple CVEs;
    the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be     started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory     assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These     hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of     pages). In some cases the hypervisor carries out the requests by splitting them into smaller chunks. Error     handling in certain PoD cases has been insufficient in that in particular partial success of some     operations was not properly accounted for. There are two code paths affected - page removal     (CVE-2021-28705) and insertion of new pages (CVE-2021-28709). (We provide one patch which combines the fix     to both issues.) (CVE-2021-28705, CVE-2021-28709)

  - guests may exceed their designated memory limit When a guest is permitted to have close to 16TiB of     memory, it may be able to issue hypercalls to increase its memory allocation beyond the administrator     established limit. This is a result of a calculation done with 32-bit precision, which may overflow. It     would then only be the overflowed (and hence small) number which gets compared against the established     upper bound. (CVE-2021-28706)

  - A flaw was found in the USB redirector device (usb-redir) of QEMU. Small USB packets are combined into a     single, large transfer request, to reduce the overhead and improve performance. The combined size of the     bulk transfer is used to dynamically allocate a variable length array (VLA) on the stack without proper     validation. Since the total size is not bounded, a malicious guest could use this flaw to influence the     array length and cause the QEMU process to perform an excessive allocation on the stack, resulting in a     denial of service. (CVE-2021-3527)

  - An invalid pointer initialization issue was found in the SLiRP networking implementation of QEMU. The flaw     exists in the bootp_input() function and could occur while processing a udp packet that is smaller than     the size of the 'bootp_t' structure. A malicious guest could use this flaw to leak 10 bytes of     uninitialized heap memory from the host. The highest threat from this vulnerability is to data     confidentiality. This flaw affects libslirp versions prior to 4.6.0. (CVE-2021-3592)

  - An invalid pointer initialization issue was found in the SLiRP networking implementation of QEMU. The flaw     exists in the udp_input() function and could occur while processing a udp packet that is smaller than the     size of the 'udphdr' structure. This issue may lead to out-of-bounds read access or indirect host memory     disclosure to the guest. The highest threat from this vulnerability is to data confidentiality. This flaw     affects libslirp versions prior to 4.6.0. (CVE-2021-3594)

  - An invalid pointer initialization issue was found in the SLiRP networking implementation of QEMU. The flaw     exists in the tftp_input() function and could occur while processing a udp packet that is smaller than the     size of the 'tftp_t' structure. This issue may lead to out-of-bounds read access or indirect host memory     disclosure to the guest. The highest threat from this vulnerability is to data confidentiality. This flaw     affects libslirp versions prior to 4.6.0. (CVE-2021-3595)

  - A flaw was found in the USB redirector device emulation of QEMU in versions prior to 6.1.0-rc2. It occurs     when dropping packets during a bulk transfer from a SPICE client due to the packet queue being full. A     malicious SPICE client could use this flaw to make QEMU call free() with faked heap chunk metadata,     resulting in a crash of QEMU or potential code execution with the privileges of the QEMU process on the     host. (CVE-2021-3682)

  - An off-by-one error was found in the SCSI device emulation in QEMU. It could occur while processing MODE     SELECT commands in mode_sense_page() if the 'page' argument was set to MODE_PAGE_ALLS (0x3f). A malicious     guest could use this flaw to potentially crash QEMU, resulting in a denial of service condition.
    (CVE-2021-3930)

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

リモートの SUSE Linux SLES11 ホストには、SUSE-SU-2021:14848-1 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - 一部の Intel(R) プロセッサの反応に不一致が見られるため、認証されたユーザーがローカルアクセスを介して情報漏洩を引き起こす可能性があります。(CVE-2021-0089)

  - 無限再帰によるスタックオーバーフローの脆弱性が、QEMU の eepro100 i8255x デバイスエミュレーターに見つかりました。この問題はコントローラーコマンドの処理中に発生し、DMA の再エントリの問題が原因です。この欠陥により、ゲストユーザーが CPU サイクルを消費したり、ホスト上で QEMU プロセスをクラッシュさせたりし、サービス拒否を引き起こすことが可能です。この脆弱性が最大の脅威となるのは、システムの可用性です。(CVE-2021-20255)

  - x86: S3 の後に TSX Async Abort 保護が復元されない。この問題は TSX Async Abort の投機的セキュリティの脆弱性に関連しています。詳細については、https://xenbits.xen.org/xsa/advisory-305.html を参照してください。
    TSX (デフォルトおよび優先オプション) を無効にすることで TAA を緩和するには、MSR_TSX_CTRL で非デフォルト設定を選択する必要があります。この設定は S3 の一時停止後に復元されません。(CVE-2021-28690)

  - 不適切な x86 IOMMU タイムアウトの検出/処理は、これらのコマンドを発行した CPU の動作と並行して、発行された IOMMU のコマンドを処理します。Xen での現在の実装では、このようなコマンドの完了の非同期通知は使用されません。代わりに、発行 CPU は、最後に発行されたコマンドの完了をスピン待機します。これらの待機ループのいくつかは、タイムアウトを適用して、過剰に時間がかかるコマンドを失敗させようとします。認識されたタイムアウトが実際に検出される一連のアクションは不適切です: - 元々タイムアウトを引き起こさなかった Intel ハードウェアゲストでは、クラッシュとマークされる場合があります。- AMD ハードウェアでは、より高いレイヤーの呼び出し元に問題が通知されず、あたかも IOMMU 操作が成功したかのように続行します。(CVE-2021-28692)

  - グラントテーブルv2のステータスページが、割り当て解除のゲストがメモリの Xen 所有の特定のページへのアクセスを許可された後に、アクセス可能のままになることがあります。このようなページの大部分は、全有効期間のゲストに割り当てられた/関連付けられた状態を維持します。しかしながら、グラントテーブル v2 のステータスページは、ゲストが v2 から v1 にスイッチ (バック) すると、割り当てが解除されます。このようなページを解放するには、ハイパーバイザーがこれらのページがゲストのどこにマップされているかを知っている必要があります。ハイパーバイザーはゲスト空間内で 1 つの使用のみを追跡しますが、これらのページのマッピングを挿入するゲストからのリクエストを競合させることで、これらのページのいずれかが複数の場所でマッピングされる可能性があります。
    v2 から v1 にスイッチバックすると、解放され、おそらく他の目的で再利用されたページへのアクセス権をゲストは保持します。(CVE-2021-28697)

  - リソースの使用を適切に監視するために、長時間の実行はグラントテーブルの処理においてループします。Xen はドメインが他のドメインによって提供された許可をマッピングするために作成する場合がある、グラントマッピングの情報を維持します。特定のアクションを実行するプロセスで、Xen はそのようなエントリをすべて繰り返し処理します。これには、すでに使用されていないものや、作成されたものの使用されていないものが含まれます。特定のドメインに対するエントリ数が十分に大きい場合、テーブル全体のこの反復により CPU が過剰に長く拘束され、他のドメインを枯渇させたり、ハイパーバイザー自体で問題が引き起こされたりする可能性があります。注意: ドメインは、自身の許可をマッピングする可能性があります。つまり、
    複数のドメインを関与させる必要はありません。しかしながら、1 組のゲストが協力している場合は、より深刻な影響を引き起こす可能性があります。(CVE-2021-28698)

  - ゲストを処理する XENMAPSPACE_grant_table ゲストの別の競合に、特定の Xen 所有メモリページへのアクセスが許可されています。このようなページの大部分は、全有効期間のゲストに割り当てられた/関連付けられた状態を維持します。
    しかしながら、グラントテーブルv2のステータスページは、ゲストが v2 から v1 にスイッチ (バック) すると、割り当てが解除されます。そのようなページを解放するには、パラレルリクエストがそのようなページのゲストへのマッピングを追加できないように、ハイパーバイザーが強制する必要があります。この強制が欠落しており、ゲストが解放され、おそらく他の目的で再利用されたページへのアクセスを保持することが可能でした。残念ながら、XSA-379が準備されていたとき、この類似した問題は気づかれませんでした。(CVE-2021-28701)

  - グラントテーブル v2 のステータスページが、割り当て解除の (テイク 2) ゲストがメモリの Xen 所有の特定のページへのアクセスを許可された後に、アクセス可能のままになることがあります。このようなページの大部分は、全有効期間のゲストに割り当てられた/関連付けられた状態を維持します。しかしながら、グラントテーブル v2 のステータスページは、ゲストが v2 から v1 にスイッチ (バック) すると、割り当てが解除されます。このようなページを解放するには、ハイパーバイザーがこれらのページがゲストのどこにマップされているかを知っている必要があります。ハイパーバイザーはゲスト空間内で 1 つの使用のみを追跡しますが、これらのページのマッピングを挿入するゲストからのリクエストを競合させることで、これらのページのいずれかが複数の場所でマッピングされる可能性があります。v2 から v1 にスイッチバックすると、解放され、おそらく他の目的で再利用されたページへのアクセス権をゲストは保持します。このバグは Xen 4.14 のコードのクリーンアップで偶発的に修正され、XSA-378 の修正の前提条件としてセキュリティがサポートされている Xen ブランチにバックポートされました。(CVE-2021-28703)

  - x86 での部分的に成功した P2M 更新の問題 [この CNA 情報レコードは複数の CVE に関連しています。
    テキストには、各側面/脆弱性がどの CVE に対応するかがを説明します。] x86 HVMおよびPVHゲストは、後でより多くのメモリを簡単に割り当てる方法を提供するために、populate-on-demand (PoD ) モードで起動できます。ゲストは、ハイパーコールを介して個々のページの特定の P2M の側面を制御できます。これらのハイパーコールは、ページ順序で指定されたページの範囲で動作する可能性があります (結果として、2 のべき乗のページ数になります)。場合によっては、ハイパーバイザーがリクエストを小さなチャンクに分割することで実行します。特定の PoD ケースでのエラー処理が不十分であり、一部の操作の特に部分的な成功が適切に考慮されていませんでした。影響を受けるコードパスは 2 つあります - ページ削除 (CVE-2021-28705) と新しいページの挿入 (CVE-2021-28709) です。(両方の問題に対する修正を組み合わせた 1 つのパッチを提供しています。) (CVE-2021-28705、CVE-2021-28709)

  - ゲストが指定されたメモリ制限を超える可能性があります。ゲストが 16 TiB に近いメモリを持つことが許可されると、ハイパーコールを発行して、管理者が設定した制限を超えてメモリ割り当てを増やせる場合があります。これは、32 ビット精度で行われた計算の結果であり、オーバーフローする可能性があります。その場合、確立された上限と比較されるのは、オーバーフローした (したがって小さな) 数値のみです。(CVE-2021-28706)

  - QEMUのUSBリダイレクタデバイス (usb-redir ) に欠陥が見つかりました。小さな USB パケットが単一の大きな転送リクエストに結合され、オーバーヘッドを削減し、パフォーマンスを向上させます。バルク転送の合計サイズは、スタックに可変長配列 (VLA) を、適切に検証せずに、動的に割り当てるために使用されます。合計サイズが制限されていないため、悪意のあるゲストがこの欠陥を利用して、配列の長さに影響を与え、QEMU プロセスにスタック上で過剰な割り当てを実行させ、サービス拒否を引き起こす可能性があります。(CVE-2021-3527)

  - QEMU の SLiRP ネットワーキングの実装で、無効なポインター初期化の問題が見つかりました。この欠陥は bootp_input() 関数に存在し、「bootp_t」構造のサイズよりも小さい udp パケットを処理する際に発生する可能性があります。悪意のあるゲストがこの欠陥を利用して、ホストから初期化されていないヒープメモリのうち 10 バイトを漏洩する可能性があります。この脆弱性による主な脅威は、データの機密性に関するものです。この欠陥は、4.6.0 より前の libslirp バージョンに影響を与えます。(CVE-2021-3592)

  - QEMU の SLiRP ネットワーキングの実装で、無効なポインター初期化の問題が見つかりました。この欠陥は udp_input() 関数に存在し、「udphdr」構造のサイズよりも小さい udp パケットを処理する際に発生する可能性があります。この問題は、領域外の読み取りアクセスまたはゲストに対する間接的なホストメモリ漏洩につながる可能性があります。この脆弱性による主な脅威は、データの機密性に関するものです。この欠陥は、4.6.0 より前の libslirp バージョンに影響を与えます。(CVE-2021-3594)

  - QEMU の SLiRP ネットワーキングの実装で、無効なポインター初期化の問題が見つかりました。この欠陥は tftp_input() 関数に存在し、「tftp_t」構造のサイズよりも小さい udp パケットを処理する際に発生する可能性があります。この問題は、領域外の読み取りアクセスまたはゲストに対する間接的なホストメモリ漏洩につながる可能性があります。この脆弱性による主な脅威は、データの機密性に関するものです。この欠陥は、4.6.0 より前の libslirp バージョンに影響を与えます。(CVE-2021-3595)

  - 6.1.0-rc2 より前のバージョンの QEMU の USB リダイレクタデバイスのエミュレーションに欠陥が見つかりました。これは、パケットキューがいっぱいであるため、SPICE クライアントからのバルク転送中にパケットをドロップするときに発生します。悪意のある SPICE クライアントがこの欠陥を利用して、偽造されたヒープチャンクメタデータで QEMU 呼び出しを free() にし、QEMU のクラッシュを引き起こしたり、ホストの QEMU プロセスの権限でコードを実行したりする可能性があります。(CVE-2021-3682)

  - QEMU の SCSI デバイスエミュレーションで off-by-one エラーが見つかりました。「page」引数が MODE_PAGE_ALLS (0x3f) に設定されている場合、mode_sense_page() の MODE SELECT コマンドの処理中にそれが発生する可能性があります。悪意のあるゲストがこの欠陥を利用して、QEMU をクラッシュさせ、サービス拒否状態を引き起こす可能性があります。
    (CVE-2021-3930)

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

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

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

  - 在取消配置 (第二次) 來賓機獲得某些 Xen 擁有的記憶體頁面的存取權後，授予表格 v2 狀態頁面仍可存取。大多數此類頁面在其整個生命週期內都會保持與來賓機的配置/關聯關係。但是，當來賓機從 v2 切換 (返回) 到 v1 時，授權表 v2 狀態頁面會解除配置。釋放這類頁面需要 Hypervisor 知道這些頁面在來賓機中的具體對應位置。Hypervisor 只追踪來賓機空間中的一個使用，但來賓機請求插入這些頁面的對應的爭用要求，可能導致其中任何一個頁面變成在多個位置進行對應。當從 v2 切換回 v1 時，來賓機會保留對已釋放頁面的存取權，而且可能會將其重新用於其他目的。此錯誤已透過清理 Xen 4.14 中的程式碼修正，並作為 XSA-378 修正的先決條件反向移植至安全性支援的 Xen 分支。(CVE-2021-28703)

  - 未對齊的 GFN 上的 PoD 作業 [他的 CNA 資訊記錄與多個 CVE 有關；文字說明了哪些方面/弱點對應於哪些 CVE。] x86 HVM 和 PVH 來賓可在 populate-on-demand (PoD) 模式下啟動，以便為它們提供稍後輕鬆指派更多記憶體的方式。允許來賓透過 hypercall 控制個別頁面的某些 P2M 方面。這些 hypercall 可作用於透過頁面順序指定的頁面範圍 (導致頁面數量為 2 的冪)。PoD 的某些 hypercall 實作並未強制基本頁面框架編號與指定順序適當對齊，但 PoD 處理中涉及的某些程式碼實際上會做出此類假設。這些作業包括 XENMEM_decrease_reservation (CVE-2021-28704) 和 XENMEM_populate_physmap (CVE-2021-28707)，但後者只能由控制來賓的網域使用，即取消權限的 qemu 或虛設網域。
    (修補程式 1，結合了這兩個問題的修正。)此外，當指定的頁面順序不是 4k、2M 或 1G (CVE-2021-28708，修補程式 2) 時，處理 XENMEM_decrease_reservation 也會觸發主機當機。 (CVE-2021-28704、CVE-2021-28707、CVE-2021-28708)

  - x86 T 上部分成功的 P2M 更新問題[他的 CNA 資訊記錄與多個 CVE 有關；
    文字說明了哪些方面/弱點對應於哪些 CVE。] x86 HVM 和 PVH 來賓可在 populate-on-demand (PoD) 模式下啟動，以便為它們提供稍後輕鬆指派更多記憶體的方式。允許來賓透過 hypercall 控制個別頁面的某些 P2M 方面。這些 hypercall 可作用於透過頁面順序指定的頁面範圍 (導致頁面數量為 2 的冪)。在某些情況下，hypervisor 會透過將要求分割成更小的區塊來執行這些要求。某些 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」）後，正在進行的日誌臟超級調用處於活躍狀態。適當定時的 XEN_DMOP_track_dirty_vram 呼叫可啟用已變更記錄，而另一個 CPU 則仍在拆除與先前啟用的記錄變更模式 (XEN_DOMCTL_SHADOW_OP_OFF) 相關的結構。這是因為兩項作業之間缺少互斥鎖定，導致在已釋放的插槽中新增項目，進而造成記憶體洩漏。
    (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 可能需要暫時配置大量記憶體。只有在要求完全完成後，才會釋放此記憶體。只有在來賓從 Ring 頁面讀取要求的回應訊息後，才會認為要求已完成。因此，未讀取回應的來賓可造成 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 shadow plus log-dirty 模式中的釋放後使用弱點。在需要主機協助位址轉譯但未提供硬體協助索引標籤 (HAP) 的環境中，Xen 會在所謂的影子模式下執行來賓。
    影子模式會維護用於影子索引標籤表和輔助資料結構的記憶體集區。為了移轉或快速檢視來賓，Xen 會另外以所謂的 log-dirty 模式執行這些作業。log-dirty 追蹤所需的資料結構屬於上述輔助資料的一部分。為了將錯誤處理工作保持在合理的範圍內，對於可能需要記憶體配置的作業，影子模式邏輯會預先確保有足夠的記憶體可用於最壞的情況。
    遺憾的是，雖然在可能需要建立新影子的程式碼路徑上正確考慮了索引標籤表記憶體，但並未將 log-dirty 基礎結構的需求納入考量。因此，程式可立即再次釋放剛建立的影子索引標籤表，而其他程式碼仍假設這些索引標籤表仍處於已配置狀態，所以仍在存取這些索引標籤表。(CVE-2022-42332)

  - x86/HVM 釘選快取屬性錯誤處理。[此 CNA 資訊記錄與多個 CVE 有關；文字說明哪些方面/弱點對應於哪些 CVE。] 為允許對具有傳遞裝置的 HVM 來賓進行快取控制，有一個可明確覆寫預設值的介面，此介面原本會採用其他方式。此介面雖然不會暴露給受影響的來賓本身，但它是專門針對控制此類來賓的網域而存在的。因此，此介面可能會被非完整權限的實體利用，例如在 Dom0 中執行取消權限的 qemu，或在所謂的 stub-domain 中執行的 qemu。在此情形下，問題在於此類受控制區域的數量不受限制 (CVE-2022-42333)，此類區域的安裝和移除未正確序列化 (CVE-2022-42334)。(CVE-2022-42333、CVE-2022-42334)

  - x86 分頁任意指標解除參照 在需要主機協助位址轉譯但未提供硬體協助索引標籤 (HAP) 的環境中，Xen 會在所謂的影子模式下執行來賓。
    由於對用於處理陰影頁面的 Hypervisor 常式檢查過於寬鬆，成功傳遞 PCI 裝置的來賓可能造成 Hypervisor 存取部分在來賓控制之下的任意指標。(CVE-2022-42335)

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

ID	Name	Product	Family	Published	Updated	Severity
189976	GLSA-202402-07 : Xen: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	2/4/2024	2/4/2024	high
155812	SUSE SLES11 Security Update : xen (SUSE-SU-2021:14848-1)	Nessus	SuSE Local Security Checks	12/2/2021	7/13/2023	high
155812	SUSE SLES11 セキュリティ更新プログラム: xen (SUSE-SU-2021:14848-1)	Nessus	SuSE Local Security Checks	12/2/2021	7/13/2023	high
189976	GLSA-202402-07：Xen：多个漏洞	Nessus	Gentoo Local Security Checks	2/4/2024	2/4/2024	high
189976	GLSA-202402-07：Xen：多個弱點	Nessus	Gentoo Local Security Checks	2/4/2024	2/4/2024	high

Detections

Analytics

Plugins Search

high

high

high

high

high