An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86 HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86 HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests with more than one vCPU can exploit the vulnerability.

This plugin has been deprecated as it does not adhere to established standards for this style of check.

The remote Ubuntu 20.04 LTS host has packages installed that are affected by multiple vulnerabilities as referenced in the USN-5617-1 advisory.

    It was discovered that memory contents previously stored in microarchitectural special registers after     RDRAND, RDSEED, and SGX EGETKEY read operations on Intel client and Xeon E3 processors may be briefly     exposed to processes on the same or different processor cores. A local attacker could use this to expose     sensitive information. (CVE-2020-0543)

    Julien Grall discovered that Xen incorrectly handled memory barriers on ARM-based systems. An attacker     could possibly use this issue to cause a denial of service, obtain sensitive information or escalate     privileges. (CVE-2020-11739)

    Ilja Van Sprundel discovered that Xen incorrectly handled profiling of guests. An unprivileged attacker     could use this issue to obtain sensitive information from other guests, cause a denial of service or     possibly gain privileges. (CVE-2020-11740, CVE-2020-11741)

    It was discovered that Xen incorrectly handled grant tables. A malicious guest could possibly use this     issue to cause a denial of service. (CVE-2020-11742, CVE-2020-11743)

    Jan Beulich discovered that Xen incorrectly handled certain code paths. An attacker could possibly use     this issue to cause a denial of service. (CVE-2020-15563)

    Julien Grall discovered that Xen incorrectly verified memory addresses provided by the guest on ARM-based     systems. A malicious guest administrator could possibly use this issue to cause a denial of service.
    (CVE-2020-15564)

    Roger Pau Monn discovered that Xen incorrectly handled caching on x86 Intel systems. An attacker could     possibly use this issue to cause a denial of service. (CVE-2020-15565)

    It was discovered that Xen incorrectly handled error in event-channel port allocation. A malicious guest     could possibly use this issue to cause a denial of service. (CVE-2020-15566)

    Jan Beulich discovered that Xen incorrectly handled certain EPT (Extended Page Tables).

    An attacker could possibly use this issue to cause a denial of service, data corruption or privilege     escalation. (CVE-2020-15567)

    Andrew Cooper discovered that Xen incorrectly handled PCI passthrough. An attacker could possibly use this     issue to cause a denial of service. (CVE-2020-25595)

    Andrew Cooper discovered that Xen incorrectly sanitized path injections. An attacker could possibly use     this issue to cause a denial of service. (CVE-2020-25596)

    Jan Beulich discovered that Xen incorrectly handled validation of event channels. An attacker could     possibly use this issue to cause a denial of service. (CVE-2020-25597)

    Julien Grall and Jan Beulich discovered that Xen incorrectly handled resetting event channels. An attacker     could possibly use this issue to cause a denial of service or obtain sensitive information.
    (CVE-2020-25599)

    Julien Grall discovered that Xen incorrectly handled event channels memory allocation on 32-bits domains.
    An attacker could possibly use this issue to cause a denial of service. (CVE-2020-25600)

    Jan Beulich discovered that Xen incorrectly handled resetting or cleaning up event channels. An attacker     could possibly use this issue to cause a denial of service. (CVE-2020-25601)

    Andrew Cooper discovered that Xen incorrectly handled certain Intel specific MSR (Model Specific     Registers). An attacker could possibly use this issue to cause a denial of service. (CVE-2020-25602)

    Julien Grall discovered that Xen incorrectly handled accessing/allocating event channels. An attacker     could possibly use this issue to cause a denial of service, obtain sensitive information of privilege     escalation. (CVE-2020-25603)

    Igor Druzhinin discovered that Xen incorrectly handled locks. An attacker could possibly use this issue to     cause a denial of service. (CVE-2020-25604)

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

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-2020:14521-1 advisory.

  - Incomplete cleanup from specific special register read operations in some Intel(R) Processors may allow an     authenticated user to potentially enable information disclosure via local access. (CVE-2020-0543)

  - An out-of-bounds read/write access flaw was found in the USB emulator of the QEMU in versions before     5.2.0. This issue occurs while processing USB packets from a guest when USBDevice 'setup_len' exceeds its     'data_buf[4096]' in the do_token_in, do_token_out routines. This flaw allows a guest user to crash the     QEMU process, resulting in a denial of service, or the potential execution of arbitrary code with the     privileges of the QEMU process on the host. (CVE-2020-14364)

  - An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS     denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When     page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs. Furthermore,     IOMMUs may be non-coherent, and hence prior to flushing IOMMU TLBs, a CPU cache also needs writing back to     memory after changes were made. Such writing back of cached data was missing in particular when splitting     large page mappings into smaller granularity ones. A malicious guest may be able to retain read/write DMA     access to frames returned to Xen's free pool, and later reused for another purpose. Host crashes (leading     to a Denial of Service) and privilege escalation cannot be ruled out. Xen versions from at least 3.2     onwards are affected. Only x86 Intel systems are affected. x86 AMD as well as Arm systems are not     affected. Only x86 HVM guests using hardware assisted paging (HAP), having a passed through PCI device     assigned, and having page table sharing enabled can leverage the vulnerability. Note that page table     sharing will be enabled (by default) only if Xen considers IOMMU and CPU large page size support     compatible. (CVE-2020-15565)

  - An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a     denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested     paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes. Depending on     the compiler version and optimisation flags, Xen might expose a dangerous partially written PTE to the     hardware, which an attacker might be able to race to exploit. A guest administrator or perhaps even an     unprivileged guest user might be able to cause denial of service, data corruption, or privilege     escalation. Only systems using Intel CPUs are vulnerable. Systems using AMD CPUs, and Arm systems, are not     vulnerable. Only systems using nested paging (hap, aka nested paging, aka in this case Intel EPT) are     vulnerable. Only HVM and PVH guests can exploit the vulnerability. The presence and scope of the     vulnerability depends on the precise optimisations performed by the compiler used to build Xen. If the     compiler generates (a) a single 64-bit write, or (b) a series of read-modify-write operations in the same     order as the source code, the hypervisor is not vulnerable. For example, in one test build using GCC 8.3     with normal settings, the compiler generated multiple (unlocked) read-modify-write operations in source-     code order, which did not constitute a vulnerability. We have not been able to survey compilers;
    consequently we cannot say which compiler(s) might produce vulnerable code (with which code-generation     options). The source code clearly violates the C rules, and thus should be considered vulnerable.
    (CVE-2020-15567)

  - An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data.
    Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device     hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect     these registers, experience shows that it's very common for devices to have out-of-spec backdoor     operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen,     leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks     cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are     vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to     leverage the vulnerability. Only systems passing through devices with out-of-spec (backdoor)     functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you     have reason to believe that your device does not have such functionality, it's better to assume that it     does. (CVE-2020-25595)

  - An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via     SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's     sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the     guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP     fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel,     resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems     are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction     in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs     are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests     cannot exploit the vulnerability. (CVE-2020-25596)

  - An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid     event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that     an event channel, once valid, will not become invalid over the life time of a guest. However, operations     like the resetting of all event channels may involve decreasing one of the bounds checked when determining     validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to     crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards     are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests     permitted to create more than the default number of event channels are vulnerable. This number depends on     the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and     for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this     number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems     using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting     max_event_channels, are not vulnerable. (CVE-2020-25597)

  - An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86     domains. The so called 2-level event channel model imposes different limits on the number of usable event     channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only     1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas     all other domains can use up to 4095 in this model. The recording of the respective limit during domain     initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to     actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the     limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0)     servicing other domains may observe event channel allocations to succeed when they should really fail.
    Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared     info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This     may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are     vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other     domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable. (CVE-2020-25600)

  - An issue was discovered in Xen through 4.14.x. There is a lack of preemption in evtchn_reset() /     evtchn_destroy(). In particular, the FIFO event channel model allows guests to have a large number of     event channels active at a time. Closing all of these (when resetting all event channels or when cleaning     up after the guest) may take extended periods of time. So far, there was no arrangement for preemption at     suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these     operations. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the     entire system. All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable     depends on underlying hardware characteristics. (CVE-2020-25601)

  - An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating     an event channel. Event channels control structures can be accessed lockless as long as the port is     considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to     prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a     hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot     be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend     on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the     vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not     been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code     (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm     systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU     vendor. x86 systems are only vulnerable if a compiler performs re-ordering. (CVE-2020-25603)

  - An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86     HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a     second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The     most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All     versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86     HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests     with more than one vCPU can exploit the vulnerability. (CVE-2020-25604)

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

The remote OracleVM system is missing necessary patches to address security updates:

  - An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data.
    Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device     hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect     these registers, experience shows that it's very common for devices to have out-of-spec backdoor     operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen,     leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks     cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are     vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to     leverage the vulnerability. Only systems passing through devices with out-of-spec (backdoor)     functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you     have reason to believe that your device does not have such functionality, it's better to assume that it     does. (CVE-2020-25595)

  - An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid     event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that     an event channel, once valid, will not become invalid over the life time of a guest. However, operations     like the resetting of all event channels may involve decreasing one of the bounds checked when determining     validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to     crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards     are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests     permitted to create more than the default number of event channels are vulnerable. This number depends on     the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and     for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this     number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems     using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting     max_event_channels, are not vulnerable. (CVE-2020-25597)

  - An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of     EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77)     can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses     or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that     of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information     leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier     are not vulnerable. (CVE-2020-25599)

  - An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86     domains. The so called 2-level event channel model imposes different limits on the number of usable event     channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only     1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas     all other domains can use up to 4095 in this model. The recording of the respective limit during domain     initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to     actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the     limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0)     servicing other domains may observe event channel allocations to succeed when they should really fail.
    Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared     info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This     may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are     vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other     domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable. (CVE-2020-25600)

  - An issue was discovered in Xen through 4.14.x. There is a lack of preemption in evtchn_reset() /     evtchn_destroy(). In particular, the FIFO event channel model allows guests to have a large number of     event channels active at a time. Closing all of these (when resetting all event channels or when cleaning     up after the guest) may take extended periods of time. So far, there was no arrangement for preemption at     suitable intervals, allowing a CPU to spend an almost unbounded amount of time in the processing of these     operations. Malicious or buggy guest kernels can mount a Denial of Service (DoS) attack affecting the     entire system. All Xen versions are vulnerable in principle. Whether versions 4.3 and older are vulnerable     depends on underlying hardware characteristics. (CVE-2020-25601)

  - An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating     an event channel. Event channels control structures can be accessed lockless as long as the port is     considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to     prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a     hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot     be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend     on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the     vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not     been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code     (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm     systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU     vendor. x86 systems are only vulnerable if a compiler performs re-ordering. (CVE-2020-25603)

  - An issue was discovered in Xen through 4.14.x. There is a race condition when migrating timers between x86     HVM vCPUs. When migrating timers of x86 HVM guests between its vCPUs, the locking model used allows for a     second vCPU of the same guest (also operating on the timers) to release a lock that it didn't acquire. The     most likely effect of the issue is a hang or crash of the hypervisor, i.e., a Denial of Service (DoS). All     versions of Xen are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only x86     HVM guests can leverage the vulnerability. x86 PV and PVH cannot leverage the vulnerability. Only guests     with more than one vCPU can exploit the vulnerability. (CVE-2020-25604)

  - An issue was discovered in Xen through 4.14.x allowing x86 HVM and PVH guest OS users to cause a denial of     service (data corruption), cause a data leak, or possibly gain privileges because coalescing of per-page     IOMMU TLB flushes is mishandled. (CVE-2020-27671)

  - An issue was discovered in Xen through 4.14.x allowing x86 guest OS users to cause a host OS denial of     service, achieve data corruption, or possibly gain privileges by exploiting a race condition that leads to     a use-after-free involving 2MiB and 1GiB superpages. (CVE-2020-27672)

  - Xen through 4.14.x allows guest OS administrators to obtain sensitive information (such as AES keys from     outside the guest) via a side-channel attack on a power/energy monitoring interface, aka a Platypus     attack. NOTE: there is only one logically independent fix: to change the access control for each such     interface in Xen. (CVE-2020-28368)

  - An issue was discovered in Xen through 4.14.x allowing x86 HVM guest OS users to cause a denial of service     (stack corruption), cause a data leak, or possibly gain privileges because of an off-by-one error. NOTE:
    this issue is caused by an incorrect fix for CVE-2020-27671. (CVE-2020-29040)

  - An issue was discovered in Xen through 4.14.x. Neither xenstore implementation does any permission checks     when reporting a xenstore watch event. A guest administrator can watch the root xenstored node, which will     cause notifications for every created, modified, and deleted key. A guest administrator can also use the     special watches, which will cause a notification every time a domain is created and destroyed. Data may     include: number, type, and domids of other VMs; existence and domids of driver domains; numbers of virtual     interfaces, block devices, vcpus; existence of virtual framebuffers and their backend style (e.g.,     existence of VNC service); Xen VM UUIDs for other domains; timing information about domain creation and     device setup; and some hints at the backend provisioning of VMs and their devices. The watch events do not     contain values stored in xenstore, only key names. A guest administrator can observe non-sensitive domain     and device lifecycle events relating to other guests. This information allows some insight into overall     system configuration (including the number and general nature of other guests), and configuration of other     guests (including the number and general nature of other guests' devices). This information might be     commercially interesting or might make other attacks easier. There is not believed to be exposure of     sensitive data. Specifically, there is no exposure of VNC passwords, port numbers, pathnames in host and     guest filesystems, cryptographic keys, or within-guest data. (CVE-2020-29480)

  - An issue was discovered in Xen through 4.14.x. Access rights of Xenstore nodes are per domid.
    Unfortunately, existing granted access rights are not removed when a domain is being destroyed. This means     that a new domain created with the same domid will inherit the access rights to Xenstore nodes from the     previous domain(s) with the same domid. Because all Xenstore entries of a guest below     /local/domain/<domid> are being deleted by Xen tools when a guest is destroyed, only Xenstore entries of     other guests still running are affected. For example, a newly created guest domain might be able to read     sensitive information that had belonged to a previously existing guest domain. Both Xenstore     implementations (C and Ocaml) are vulnerable. (CVE-2020-29481)

  - An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page     using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that     guest. Unfortunately, this is done by just removing the guest from xenstored's internal management,     resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain     event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must     look at the states of all guests to find the guest that has been removed. When an @releaseDomain is     generated due to a domain xenstored protocol violation, because the guest is still running, the watchers     will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in     its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain;
    memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain     will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain     event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a     use-after-free case could happen in xenstored, after having removed the guest from its internal data base,     possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period     after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a     more serious denial of service (the prevention of any further domain management operations). Only the C     variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device     model can cause a serious DoS. (CVE-2020-29483)

  - An issue was discovered in Xen through 4.14.x. When a Xenstore watch fires, the xenstore client that     registered the watch will receive a Xenstore message containing the path of the modified Xenstore entry     that triggered the watch, and the tag that was specified when registering the watch. Any communication     with xenstored is done via Xenstore messages, consisting of a message header and the payload. The payload     length is limited to 4096 bytes. Any request to xenstored resulting in a response with a payload longer     than 4096 bytes will result in an error. When registering a watch, the payload length limit applies to the     combined length of the watched path and the specified tag. Because watches for a specific path are also     triggered for all nodes below that path, the payload of a watch event message can be longer than the     payload needed to register the watch. A malicious guest that registers a watch using a very large tag     (i.e., with a registration operation payload length close to the 4096 byte limit) can cause the generation     of watch events with a payload length larger than 4096 bytes, by writing to Xenstore entries below the     watched path. This will result in an error condition in xenstored. This error can result in a NULL pointer     dereference, leading to a crash of xenstored. A malicious guest administrator can cause xenstored to     crash, leading to a denial of service. Following a xenstored crash, domains may continue to run, but     management operations will be impossible. Only C xenstored is affected, oxenstored is not affected.
    (CVE-2020-29484)

  - An issue was discovered in Xen through 4.14.x. Recording of the per-vCPU control block mapping maintained     by Xen and that of pointers into the control block is reversed. The consumer assumes, seeing the former     initialized, that the latter are also ready for use. Malicious or buggy guest kernels can mount a Denial     of Service (DoS) attack affecting the entire system. (CVE-2020-29570)

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

This update for xen fixes the following issues :

CVE-2020-25604: Fixed a race condition when migrating timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

CVE-2020-25595: Fixed an issue where PCI passthrough code was reading back hardware registers (bsc#1176344,XSA-337)

CVE-2020-25597: Fixed an issue where a valid event channels may not turn invalid (bsc#1176346,XSA-338)

CVE-2020-25596: Fixed a potential denial of service in x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

CVE-2020-25603: Fixed an issue due to missing barriers when accessing/allocating an event channel (bsc#1176347,XSA-340)

CVE-2020-25600: Fixed out of bounds event channels available to 32-bit x86 domains (bsc#1176348,XSA-342)

CVE-2020-25599: Fixed race conditions with evtchn_reset() (bsc#1176349,XSA-343)

CVE-2020-25601: Fixed an issue due to lack of preemption in evtchn_reset() / evtchn_destroy() (bsc#1176350,XSA-344)

CVE-2020-14364: Fixed an out-of-bounds read/write access while processing usb packets (bsc#1175534).

Various bug fixes (bsc#1027519)

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

This update for xen fixes the following issues :

CVE-2020-25602: Fixed an issue where there was a crash when handling guest access to MSR_MISC_ENABLE was thrown (bsc#1176339,XSA-333)

CVE-2020-25598: Added a missing unlock in XENMEM_acquire_resource error path (bsc#1176341,XSA-334)

CVE-2020-25604: Fixed a race condition when migrating timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

CVE-2020-25595: Fixed an issue where PCI passthrough code was reading back hardware registers (bsc#1176344,XSA-337)

CVE-2020-25597: Fixed an issue where a valid event channels may not turn invalid (bsc#1176346,XSA-338)

CVE-2020-25596: Fixed a potential denial of service in x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

CVE-2020-25603: Fixed an issue due to missing barriers when accessing/allocating an event channel (bsc#1176347,XSA-340)

CVE-2020-25600: Fixed out of bounds event channels available to 32-bit x86 domains (bsc#1176348,XSA-342)

CVE-2020-25599: Fixed race conditions with evtchn_reset() (bsc#1176349,XSA-343)

CVE-2020-25601: Fixed an issue due to lack of preemption in evtchn_reset() / evtchn_destroy() (bsc#1176350,XSA-344)

CVE-2020-14364: Fixed an out-of-bounds read/write access while processing usb packets (bsc#1175534).

Various bug fixes (bsc#1027519)

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

This update for xen fixes the following issues :

CVE-2020-25604: Fixed a race condition when migrating timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

CVE-2020-25595: Fixed an issue where PCI passthrough code was reading back hardware registers (bsc#1176344,XSA-337)

CVE-2020-25597: Fixed an issue where a valid event channels may not turn invalid (bsc#1176346,XSA-338)

CVE-2020-25596: Fixed a potential denial of service in x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

CVE-2020-25603: Fixed an issue due to missing barriers when accessing/allocating an event channel (bsc#1176347,XSA-340)

CVE-2020-25600: Fixed out of bounds event channels available to 32-bit x86 domains (bsc#1176348,XSA-342)

CVE-2020-25599: Fixed race conditions with evtchn_reset() (bsc#1176349,XSA-343)

CVE-2020-25601: Fixed an issue due to lack of preemption in evtchn_reset() / evtchn_destroy() (bsc#1176350,XSA-344)

CVE-2020-14364: Fixed an out-of-bounds read/write access while processing usb packets (bsc#1175534).

CVE-2020-0543: Fixed a leak of Special Register Buffer Data Sampling (SRBDS) aka 'CrossTalk' (bsc#1172205,XSA-320)

CVE-2020-15565: Fixed an issue cache write (bsc#1173378,XSA-321).

CVE-2020-15567: Fixed an issue with non-atomic modification of live EPT PTE (bsc#1173380,XSA-328)

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

This update for xen fixes the following issues :

CVE-2020-25602: Fixed an issue where there was a crash when handling guest access to MSR_MISC_ENABLE was thrown (bsc#1176339,XSA-333)

CVE-2020-25598: Added a missing unlock in XENMEM_acquire_resource error path (bsc#1176341,XSA-334)

CVE-2020-25604: Fixed a race condition when migrating timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

CVE-2020-25595: Fixed an issue where PCI passthrough code was reading back hardware registers (bsc#1176344,XSA-337)

CVE-2020-25597: Fixed an issue where a valid event channels may not turn invalid (bsc#1176346,XSA-338)

CVE-2020-25596: Fixed a potential denial of service in x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

CVE-2020-25603: Fixed an issue due to missing barriers when accessing/allocating an event channel (bsc#1176347,XSA-340)

CVE-2020-25600: Fixed out of bounds event channels available to 32-bit x86 domains (bsc#1176348,XSA-342)

CVE-2020-25599: Fixed race conditions with evtchn_reset() (bsc#1176349,XSA-343)

CVE-2020-25601: Fixed an issue due to lack of preemption in evtchn_reset() / evtchn_destroy() (bsc#1176350,XSA-344)

Various other fixes (bsc#1027519)

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

This update for xen fixes the following issues :

CVE-2020-25602: Fixed an issue where there was a crash when handling guest access to MSR_MISC_ENABLE was thrown (bsc#1176339,XSA-333)

CVE-2020-25598: Added a missing unlock in XENMEM_acquire_resource error path (bsc#1176341,XSA-334)

CVE-2020-25604: Fixed a race condition when migrating timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

CVE-2020-25595: Fixed an issue where PCI passthrough code was reading back hardware registers (bsc#1176344,XSA-337)

CVE-2020-25597: Fixed an issue where a valid event channels may not turn invalid (bsc#1176346,XSA-338)

CVE-2020-25596: Fixed a potential denial of service in x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

CVE-2020-25603: Fixed an issue due to missing barriers when accessing/allocating an event channel (bsc#1176347,XSA-340)

CVE-2020-25600: Fixed out of bounds event channels available to 32-bit x86 domains (bsc#1176348,XSA-342)

CVE-2020-25599: Fixed race conditions with evtchn_reset() (bsc#1176349,XSA-343)

CVE-2020-25601: Fixed an issue due to lack of preemption in evtchn_reset() / evtchn_destroy() (bsc#1176350,XSA-344)

Various bug fixes (bsc#1027519)

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

The remote host is affected by the vulnerability described in GLSA-202011-06 (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.

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by a denial of service (DoS) vulnerability. When migrating timers of x86 HVM guests between its vCPU-s, the locking model used allows for a second vCPU of the same guest also operating on the timers to release a lock that it didn't acquire. An attacker can exploit this issue to crash the hypervisor and cause a DoS condition.

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

x86 pv: Crash when handling guest access to MSR_MISC_ENABLE [XSA-333, CVE-2020-25602] (#1881619) Missing unlock in XENMEM_acquire_resource error path [XSA-334, CVE-2020-25598] (#1881616) race when migrating timers between x86 HVM vCPU-s [XSA-336, CVE-2020-25604] (#1881618) PCI passthrough code reading back hardware registers [XSA-337, CVE-2020-25595] (#1881587) once valid event channels may not turn invalid [XSA-338, CVE-2020-25597] (#1881588) x86 pv guest kernel DoS via SYSENTER [XSA-339, CVE-2020-25596] (#1881617) Missing memory barriers when accessing/allocating an event channel [XSA-340, CVE-2020-25603] (#1881583) out of bounds event channels available to 32-bit x86 domains [XSA-342, CVE-2020-25600] (#1881582) races with evtchn_reset() [XSA-343, CVE-2020-25599] (#1881581) lack of preemption in evtchn_reset() / evtchn_destroy() [XSA-344, CVE-2020-25601] (#1881586)

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.

This update for xen fixes the following issues :

  - CVE-2020-25602: Fixed an issue where there was a crash     when handling guest access to MSR_MISC_ENABLE was thrown     (bsc#1176339,XSA-333)

  - CVE-2020-25598: Added a missing unlock in     XENMEM_acquire_resource error path (bsc#1176341,XSA-334)

  - CVE-2020-25604: Fixed a race condition when migrating     timers between x86 HVM vCPU-s (bsc#1176343,XSA-336)

  - CVE-2020-25595: Fixed an issue where PCI passthrough     code was reading back hardware registers     (bsc#1176344,XSA-337)

  - CVE-2020-25597: Fixed an issue where a valid event     channels may not turn invalid (bsc#1176346,XSA-338)

  - CVE-2020-25596: Fixed a potential denial of service in     x86 pv guest kernel via SYSENTER (bsc#1176345,XSA-339)

  - CVE-2020-25603: Fixed an issue due to missing barriers     when accessing/allocating an event channel     (bsc#1176347,XSA-340)

  - CVE-2020-25600: Fixed out of bounds event channels     available to 32-bit x86 domains (bsc#1176348,XSA-342)

  - CVE-2020-25599: Fixed race conditions with     evtchn_reset() (bsc#1176349,XSA-343)

  - CVE-2020-25601: Fixed an issue due to lack of preemption     in evtchn_reset() / evtchn_destroy()     (bsc#1176350,XSA-344)

  - Various other fixes (bsc#1027519)

This update was imported from the SUSE:SLE-15-SP2:Update update project.

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

ID	Name	Product	Family	Severity
196575	RHEL 5 : xen (Unpatched Vulnerability) (deprecated)	Nessus	Red Hat Local Security Checks	critical
165248	Ubuntu 20.04 LTS : Xen vulnerabilities (USN-5617-1)	Nessus	Ubuntu Local Security Checks	high
150542	SUSE SLES11 Security Update : xen (SUSE-SU-2020:14521-1)	Nessus	SuSE Local Security Checks	high
150180	OracleVM 3.4 : xen (OVMSA-2021-0014)	Nessus	OracleVM Local Security Checks	high
143873	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2787-1)	Nessus	SuSE Local Security Checks	high
143853	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2788-1)	Nessus	SuSE Local Security Checks	high
143805	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2822-1)	Nessus	SuSE Local Security Checks	high
143707	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:2791-1)	Nessus	SuSE Local Security Checks	high
143685	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2786-1)	Nessus	SuSE Local Security Checks	high
143637	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:2790-1)	Nessus	SuSE Local Security Checks	high
142854	GLSA-202011-06 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
141836	Xen Migrating Timers Race condition DoS (XSA-336)	Nessus	Misc.	medium
141278	Fedora 31 : xen (2020-d46fe34349)	Nessus	Fedora Local Security Checks	high
141270	Fedora 33 : xen (2020-306b84fd07)	Nessus	Fedora Local Security Checks	high
141168	openSUSE Security Update : xen (openSUSE-2020-1608)	Nessus	SuSE Local Security Checks	high
141138	Debian DSA-4769-1 : xen - security update	Nessus	Debian Local Security Checks	high
141102	Fedora 32 : xen (2020-f668e579be)	Nessus	Fedora Local Security Checks	high

Detections

Analytics

CVE-2020-25604

medium

Tenable Plugins

critical

high

high

high

high

high

high

high

high

high

high

medium

high

high

high

high

high