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.

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

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.

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.

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by a denial of service vulnerability. 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.

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

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
157004	GLSA-202107-30 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
150656	SUSE SLES11 Security Update : xen (SUSE-SU-2020:14578-1)	Nessus	SuSE Local Security Checks	high
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
144714	Xen xenstored watch DoS (XSA-348)	Nessus	Misc.	medium
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-29566

medium

Tenable Plugins

high

high

high

high

medium

high

high

high

high

high

high

high

high

high