An issue was discovered in Xen 4.14.x. When moving IRQs between CPUs to distribute the load of IRQ handling, IRQ vectors are dynamically allocated and de-allocated on the relevant CPUs. De-allocation has to happen when certain constraints are met. If these conditions are not met when first checked, the checking CPU may send an interrupt to itself, in the expectation that this IRQ will be delivered only after the condition preventing the cleanup has cleared. For two specific IRQ vectors, this expectation was violated, resulting in a continuous stream of self-interrupts, which renders the CPU effectively unusable. A domain with a passed through PCI device can cause lockup of a physical CPU, resulting in a Denial of Service (DoS) to the entire host. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with physical PCI devices passed through to them can exploit the vulnerability.

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

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by a denial of service vulnerability due to an issue when handling IRQ vectors. When moving IRQs between CPUs to distribute the load of IRQ handling, IRQ vectors are dynamically allocated and de-allocated on the relevant CPUs. De-allocation has to happen when certain constraints are met. If these conditions are not met when first checked, the checking CPU may send an interrupt to itself, in the expectation that this IRQ will be delivered only after the condition preventing the cleanup has cleared. For two specific IRQ vectors, this expectation was violated, resulting in a continuous stream of self-interrupts, which renders the CPU effectively unusable. A domain with a passed through PCI device can cause lockup of a physical CPU, resulting in a Denial of Service (DoS) to the entire host. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with physical PCI devices passed through to them 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.

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.

ID	Name	Product	Family	Severity
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
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
157004	GLSA-202107-30 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
144743	Xen IRQ Infinite Loop DoS (XSA-356)	Nessus	Misc.	medium
144611	Fedora 33 : xen (2020-64859a826b)	Nessus	Fedora Local Security Checks	high

Detections

Analytics

CVE-2020-29567

medium

Tenable Plugins

high

high

high

high

high

medium

high