An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions that require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.

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.13.x, allowing Arm guest OS users to cause a hypervisor crash     because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info     is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen     address space so it can be directly accessed. On Arm, the region is accessed with instructions that     require a specific alignment. Unfortunately, there is no check that the address provided by the guest will     be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a     misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of     Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not     affected. (CVE-2020-15564)

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. 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.13.x, allowing x86 HVM guest OS users to cause a hypervisor
    crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make
    Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM guest may cause
    the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Xen versions from
    4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected.
    Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In
    addition, there needs to be an entity actively monitoring a guest's video frame buffer (typically for
    display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests, as
    well as x86 HVM guests using hardware assisted paging (HAP), cannot leverage the vulnerability.
    (CVE-2020-15563)

  - An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash
    because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info
    is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen
    address space so it can be directly accessed. On Arm, the region is accessed with instructions that
    require a specific alignment. Unfortunately, there is no check that the address provided by the guest will
    be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a
    misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of
    Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not
    affected. (CVE-2020-15564)

  - 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 guest OS users to cause a host OS crash because of
    incorrect error handling in event-channel port allocation. The allocation of an event-channel port may
    fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port
    we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the
    limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1)
    will be considered an error. All the other cases will provide a valid port and will result in a crash when
    trying to access the event channel. When the administrator configured a guest to allow more than 1023
    event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new
    event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and
    later are affected. All architectures are affected. The default configuration, when guests are created
    with xl/libxl, is not vulnerable, because of the default event-channel limit. (CVE-2020-15566)

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

  - An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor
    crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make
    Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM guest may cause
    the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Xen versions from
    4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected.
    Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In
    addition, there needs to be an entity actively monitoring a guest's video frame buffer (typically for
    display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests, as
    well as x86 HVM guests using hardware assisted paging (HAP), cannot leverage the vulnerability.
    (CVE-2020-15563)

  - An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash
    because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info
    is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen
    address space so it can be directly accessed. On Arm, the region is accessed with instructions that
    require a specific alignment. Unfortunately, there is no check that the address provided by the guest will
    be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a
    misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of
    Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not
    affected. (CVE-2020-15564)

  - 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 guest OS users to cause a host OS crash because of
    incorrect error handling in event-channel port allocation. The allocation of an event-channel port may
    fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, or (3) the port
    we try to allocate is higher than what is supported by the ABI (e.g., 2L or FIFO) used by the guest or the
    limit set by an administrator (max_event_channels in xl cfg). Due to the missing error checks, only (1)
    will be considered an error. All the other cases will provide a valid port and will result in a crash when
    trying to access the event channel. When the administrator configured a guest to allow more than 1023
    event channels, that guest may be able to crash the host. When Xen is out-of-memory, allocation of new
    event channels will result in crashing the host rather than reporting an error. Xen versions 4.10 and
    later are affected. All architectures are affected. The default configuration, when guests are created
    with xl/libxl, is not vulnerable, because of the default event-channel limit. (CVE-2020-15566)

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

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

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

  - 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 issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor
    crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make
    Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM guest may cause
    the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Xen versions from
    4.8 onwards are affected. Xen versions 4.7 and earlier are not affected. Only x86 systems are affected.
    Arm systems are not affected. Only x86 HVM guests using shadow paging can leverage the vulnerability. In
    addition, there needs to be an entity actively monitoring a guest's video frame buffer (typically for
    display purposes) in order for such a guest to be able to leverage the vulnerability. x86 PV guests, as
    well as x86 HVM guests using hardware assisted paging (HAP), cannot leverage the vulnerability.
    (CVE-2020-15563)

  - An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash
    because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info
    is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen
    address space so it can be directly accessed. On Arm, the region is accessed with instructions that
    require a specific alignment. Unfortunately, there is no check that the address provided by the guest will
    be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a
    misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of
    Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not
    affected. (CVE-2020-15564)

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.

According to its self-reported version number, the Xen hypervisor installed on the remote host is affected by an issue allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be mapped into Xen address space so it can be directly accessed. On Arm, the region is accessed with instructions that require a specific alignment. Unfortunately, there is no check that the address provided by the guest will be correctly aligned. As a result, a malicious guest could cause a hypervisor crash by passing a misaligned address. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). All Xen versions are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.

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

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

incorrect error handling in event channel port allocation leads to DoS [XSA-317, CVE-2020-15566] (#1854465) inverted code paths in x86 dirty VRAM tracking leads to DoS [XSA-319, CVE-2020-15563] (#1854463) xen:
insufficient cache write-back under VT-d leads to DoS [XSA-321, CVE-2020-15565] (#1854467) missing alignment check in VCPUOP_register_vcpu_info leads to DoS [XSA-327, CVE-2020-15564] (#1854458) non-atomic modification of live EPT PTE leads to DoS [XSA-328, CVE-2020-15567] (#1854464)

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.

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
257512	Linux Distros Unpatched Vulnerability : CVE-2020-15564	Nessus	Misc.	medium
424712	Alpine: multiple xen packages: security update to 4.13.1-r4	Tenable Cloud Security	Alpine Linux Local Security Checks	high
424712	Alpine: multiple xen packages: security update to 4.13.1-r4	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407770	Alpine: xen: security update to 4.13.1-r2	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407770	Alpine: xen: security update to 4.13.1-r2	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407762	Alpine: xen: security update to 4.12.3-r2	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407762	Alpine: xen: security update to 4.12.3-r2	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407753	Alpine: xen: security update to 4.11.4-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407753	Alpine: xen: security update to 4.11.4-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
400408	Alpine: multiple xen packages: security update to 4.13.1-r3 (deprecated)	Tenable Cloud Security	Alpine Linux Local Security Checks	high
400408	Alpine: multiple xen packages: security update to 4.13.1-r3 (deprecated)	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
165248	Ubuntu 20.04 LTS : Xen vulnerabilities (USN-5617-1)	Nessus	Ubuntu Local Security Checks	high
149066	Xen Missing Alignment Check DoS (XSA-327)	Nessus	Misc.	medium
138925	GLSA-202007-02 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
138864	Fedora 31 : xen (2020-76cf2b0f0a)	Nessus	Fedora Local Security Checks	high
138535	Fedora 32 : xen (2020-fbc13516af)	Nessus	Fedora Local Security Checks	high
138394	Debian DSA-4723-1 : xen - security update	Nessus	Debian Local Security Checks	high

Detections

Analytics

CVE-2020-15564

medium

Tenable Plugins

medium

high

high

high

high

high

high

high

high

high

high

high

medium

high

high

high

high