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.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

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

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - An issue was discovered in Xen through 4.14.x. In the Ocaml xenstored implementation, the internal
    representation of the tree has special cases for the root node, because this node has no parent.
    Unfortunately, permissions were not checked for certain operations on the root node. Unprivileged guests
    can get and modify permissions, list, and delete the root node. (Deleting the whole xenstore tree is a
    host-wide denial of service.) Achieving xenstore write access is also possible. All systems using
    oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution,
    if the Ocaml compiler is available. Systems using C xenstored are not vulnerable. (CVE-2020-29479)

  - 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. A guest may access xenstore paths via absolute paths
    containing a full pathname, or via a relative path, which implicitly includes /local/domain/$DOMID for
    their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute
    paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path
    specified by the client. Therefore, a guest can create paths in its own namespace which are too long for
    management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause
    some management tools and debugging operations to fail. For example, a guest administrator can cause
    "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from
    tearing down the domain. All systems using oxenstored are vulnerable. Building and using oxenstored is the
    default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored
    are not vulnerable. (CVE-2020-29482)

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

  - slirp.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of     header data even if that exceeds the total packet length. (CVE-2020-29130)

  - 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/ 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. When they require assistance from the device model, x86 HVM     guests must be temporarily de-scheduled. The device model will signal Xen when it has completed its     operation, via an event channel, so that the relevant vCPU is rescheduled. If the device model were to     signal Xen without having actually completed the operation, the de-schedule / re-schedule cycle would     repeat. If, in addition, Xen is resignalled very quickly, the re-schedule may occur before the de-schedule     was fully complete, triggering a shortcut. This potentially repeating process uses ordinary recursive     function calls, and thus could result in a stack overflow. A malicious or buggy stubdomain serving a HVM     guest can cause Xen to crash, resulting in a Denial of Service (DoS) to the entire host. Only x86 systems     are affected. Arm systems are not affected. Only x86 stubdomains serving HVM guests can exploit the     vulnerability. (CVE-2020-29566)

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

  - An issue was discovered in Xen through 4.14.x. A bounds check common to most operation time functions     specific to FIFO event channels depends on the CPU observing consistent state. While the producer side     uses appropriately ordered writes, the consumer side isn't protected against re-ordered reads, and may     hence end up de-referencing a NULL pointer. Malicious or buggy guest kernels can mount a Denial of Service     (DoS) attack affecting the entire system. Only Arm systems may be vulnerable. Whether a system is     vulnerable depends on the specific CPU. x86 systems are not vulnerable. (CVE-2020-29571)

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.

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by an issue.
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).

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-29480: Fixed an issue which could have allowed     leak of non-sensitive data to administrator guests     (bsc#117949 XSA-115).

  - CVE-2020-29481: Fixed an issue which could have allowd     to new domains to inherit existing node permissions     (bsc#1179498 XSA-322). 

  - CVE-2020-29483: Fixed an issue where guests could     disturb domain cleanup (bsc#1179502 XSA-325).

  - CVE-2020-29484: Fixed an issue where guests could crash     xenstored via watchs (bsc#1179501 XSA-324). 

  - CVE-2020-29566: Fixed an undue recursion in x86 HVM     context switch code (bsc#1179506 XSA-348).

  - CVE-2020-29570: Fixed an issue where FIFO event channels     control block related ordering (bsc#1179514 XSA-358).

  - CVE-2020-29571: Fixed an issue where FIFO event channels     control structure ordering (bsc#1179516 XSA-359).

  - Fixed an issue where dump-core shows missing nr_pages     during core (bsc#1176782).

  - Multiple other bugs (bsc#1027519)

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

This update for xen fixes the following issues :

  - CVE-2020-29480: Fixed an issue which could have allowed     leak of non-sensitive data to administrator guests     (bsc#117949 XSA-115).

  - CVE-2020-29481: Fixed an issue which could have allowd     to new domains to inherit existing node permissions     (bsc#1179498 XSA-322). 

  - CVE-2020-29483: Fixed an issue where guests could     disturb domain cleanup (bsc#1179502 XSA-325).

  - CVE-2020-29484: Fixed an issue where guests could crash     xenstored via watchs (bsc#1179501 XSA-324). 

  - CVE-2020-29566: Fixed an undue recursion in x86 HVM     context switch code (bsc#1179506 XSA-348).

  - CVE-2020-29570: Fixed an issue where FIFO event channels     control block related ordering (bsc#1179514 XSA-358).

  - CVE-2020-29571: Fixed an issue where FIFO event channels     control structure ordering (bsc#1179516 XSA-359).

  - Fixed an issue where dump-core shows missing nr_pages     during core (bsc#1176782).

  - Multiple other bugs (bsc#1027519)

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

This update for xen fixes the following issues :

CVE-2020-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).

CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322).

CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).

CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324).

CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).

CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).

CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).

CVE-2020-29130: Fixed an out-of-bounds access while processing ARP packets (bsc#1179477).

Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).

Multiple other bugs (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.

xenstore watch notifications lacking permission checks [XSA-115, CVE-2020-29480] (#1908091) Xenstore: new domains inheriting existing node permissions [XSA-322, CVE-2020-29481] (#1908095) Xenstore: wrong path length check [XSA-323, CVE-2020-29482] (#1908096) Xenstore:
guests can crash xenstored via watchs [XSA-324, CVE-2020-29484] (#1908088) Xenstore: guests can disturb domain cleanup [XSA-325, CVE-2020-29483] (#1908087) oxenstored memory leak in reset_watches [XSA-330, CVE-2020-29485] (#1908000) undue recursion in x86 HVM context switch code [XSA-348, CVE-2020-29566] (#1908085) oxenstored:
node ownership can be changed by unprivileged clients [XSA-352, CVE-2020-29486] (#1908003) oxenstored: permissions not checked on root node [XSA-353, CVE-2020-29479] (#1908002) FIFO event channels control block related ordering [XSA-358, CVE-2020-29570] (#1907931) FIFO event channels control structure ordering [XSA-359, CVE-2020-29571] (#1908089)

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.

xenstore watch notifications lacking permission checks [XSA-115, CVE-2020-29480] (#1908091) Xenstore: new domains inheriting existing node permissions [XSA-322, CVE-2020-29481] (#1908095) Xenstore: wrong path length check [XSA-323, CVE-2020-29482] (#1908096) Xenstore:
guests can crash xenstored via watchs [XSA-324, CVE-2020-29484] (#1908088) Xenstore: guests can disturb domain cleanup [XSA-325, CVE-2020-29483] (#1908087) oxenstored memory leak in reset_watches [XSA-330, CVE-2020-29485] (#1908000) undue recursion in x86 HVM context switch code [XSA-348, CVE-2020-29566] (#1908085) oxenstored:
node ownership can be changed by unprivileged clients [XSA-352, CVE-2020-29486] (#1908003) oxenstored: permissions not checked on root node [XSA-353, CVE-2020-29479] (#1908002) infinite loop when cleaning up IRQ vectors [XSA-356, CVE-2020-29567] (#1907932) FIFO event channels control block related ordering [XSA-358, CVE-2020-29570] (#1907931) FIFO event channels control structure ordering [XSA-359, CVE-2020-29571] (#1908089)

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-29480: Fixed an issue which could have allowed leak of non-sensitive data to administrator guests (bsc#117949 XSA-115).

CVE-2020-29481: Fixed an issue which could have allowd to new domains to inherit existing node permissions (bsc#1179498 XSA-322).

CVE-2020-29483: Fixed an issue where guests could disturb domain cleanup (bsc#1179502 XSA-325).

CVE-2020-29484: Fixed an issue where guests could crash xenstored via watchs (bsc#1179501 XSA-324).

CVE-2020-29566: Fixed an undue recursion in x86 HVM context switch code (bsc#1179506 XSA-348).

CVE-2020-29570: Fixed an issue where FIFO event channels control block related ordering (bsc#1179514 XSA-358).

CVE-2020-29571: Fixed an issue where FIFO event channels control structure ordering (bsc#1179516 XSA-359).

Fixed an issue where dump-core shows missing nr_pages during core (bsc#1176782).

Multiple other bugs (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.

Multiple vulnerabilities have been discovered in the Xen hypervisor :

Several security issues affecting Xenstore could result in cross domain access (denial of service, information leaks or privilege escalation) or denial of service against xenstored.

Additional vulnerabilities could result in guest-to-host denial of service.

ID	Name	Product	Family	Severity
259103	Linux Distros Unpatched Vulnerability : CVE-2020-29483	Nessus	Misc.	medium
424699	Alpine: multiple xen packages: security update to 4.14.1-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
424699	Alpine: multiple xen packages: security update to 4.14.1-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407777	Alpine: xen: security update to 4.13.2-r3	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407777	Alpine: xen: security update to 4.13.2-r3	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
400301	Alpine: multiple xen packages: security update to 4.14.0-r3 (deprecated)	Tenable Cloud Security	Alpine Linux Local Security Checks	high
400301	Alpine: multiple xen packages: security update to 4.14.0-r3 (deprecated)	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
150656	SUSE SLES11 Security Update : xen (SUSE-SU-2020:14578-1)	Nessus	SuSE Local Security Checks	high
150180	OracleVM 3.4 : xen (OVMSA-2021-0014)	Nessus	OracleVM Local Security Checks	high
149065	Xen Xenstore Use-After-Free DoS (XSA-325)	Nessus	Misc.	medium
145360	openSUSE Security Update : xen (openSUSE-2020-2313)	Nessus	SuSE Local Security Checks	high
145322	openSUSE Security Update : xen (openSUSE-2020-2331)	Nessus	SuSE Local Security Checks	high
144637	SUSE SLES12 Security Update : xen (SUSE-SU-2020:3945-1)	Nessus	SuSE Local Security Checks	high
144613	Fedora 32 : xen (2020-df772b417b)	Nessus	Fedora Local Security Checks	high
144611	Fedora 33 : xen (2020-64859a826b)	Nessus	Fedora Local Security Checks	high
144580	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:3915-1)	Nessus	SuSE Local Security Checks	high
144576	SUSE SLES12 Security Update : xen (SUSE-SU-2020:3914-1)	Nessus	SuSE Local Security Checks	high
144570	SUSE SLES12 Security Update : xen (SUSE-SU-2020:3913-1)	Nessus	SuSE Local Security Checks	high
144492	SUSE SLES12 Security Update : xen (SUSE-SU-2020:3880-1)	Nessus	SuSE Local Security Checks	high
144476	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:3881-1)	Nessus	SuSE Local Security Checks	high
144322	Debian DSA-4812-1 : xen - security update	Nessus	Debian Local Security Checks	high

Detections

Analytics

CVE-2020-29483

medium

Tenable Plugins

medium

high

high

high

high

high

high

high

high

medium

high

high

high

high

high

high

high

high

high

high

high