An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs, typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using PV stubdomains, or with emulators running in dom0, cannot 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. 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.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. The PCI passthrough code improperly uses register data.
    Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device
    hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect
    these registers, experience shows that it's very common for devices to have out-of-spec "backdoor"
    operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen,
    leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks
    cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are
    vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to
    leverage the vulnerability. Only systems passing through devices with out-of-spec ("backdoor")
    functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you
    have reason to believe that your device does not have such functionality, it's better to assume that it
    does. (CVE-2020-25595)

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

  - An issue was discovered in Xen 4.14.x. There is a missing unlock in the XENMEM_acquire_resource error
    path. The RCU (Read, Copy, Update) mechanism is a synchronisation primitive. A buggy error path in the
    XENMEM_acquire_resource exits without releasing an RCU reference, which is conceptually similar to
    forgetting to unlock a spinlock. A buggy or malicious HVM stubdomain can cause an RCU reference to be
    leaked. This causes subsequent administration operations, (e.g., CPU offline) to livelock, resulting in a
    host Denial of Service. The buggy codepath has been present since Xen 4.12. Xen 4.14 and later are
    vulnerable to the DoS. The side effects are believed to be benign on Xen 4.12 and 4.13, but patches are
    provided nevertheless. The vulnerability can generally only be exploited by x86 HVM VMs, as these are
    generally the only type of VM that have a Qemu stubdomain. x86 PV and PVH domains, as well as ARM VMs,
    typically don't use a stubdomain. Only VMs using HVM stubdomains can exploit the vulnerability. VMs using
    PV stubdomains, or with emulators running in dom0, cannot exploit the vulnerability. (CVE-2020-25598)

A denial of service (DoS) vulnerability exists in Xen servers XENMEM_acquire_resource due to an error path exiting without releasing an RCU (Read, Copy, Update) reference. An authenticated, local attacker can exploit this issue, via a malicious HVM stubdomain which can cause an RCU reference to be leaked, that leads to subsequent administration operations, (e.g. CPU offline) to livelock, resulting in a host DoS.

This update for xen fixes the following issues :

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

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

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

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

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

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

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

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

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

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

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

Various bug fixes (bsc#1027519)

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

This update for xen fixes the following issues :

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

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

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

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

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

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

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

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

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

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

Various other fixes (bsc#1027519)

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

This update for xen fixes the following issues :

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

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

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

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

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

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

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

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

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

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

Various bug fixes (bsc#1027519)

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

The remote host is affected by the vulnerability described in GLSA-202011-06 (Xen: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in Xen. Please review the       CVE identifiers referenced below for details.
  Impact :

    Please review the referenced CVE identifiers for details.
  Workaround :

    There is no known workaround at this time.

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

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

This update for xen fixes the following issues :

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

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

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

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

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

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

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

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

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

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

  - Various other fixes (bsc#1027519)

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

ID	Name	Product	Family	Severity
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
424694	Alpine: multiple xen packages: security update to 4.14.0-r1	Tenable Cloud Security	Alpine Linux Local Security Checks	high
424694	Alpine: multiple xen packages: security update to 4.14.0-r1	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
407764	Alpine: xen: security update to 4.12.3-r4	Tenable Cloud Security	Alpine Linux Local Security Checks	high
407764	Alpine: xen: security update to 4.12.3-r4	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
400363	Alpine: multiple xen packages: security update to 4.14.0-r0 (deprecated)	Tenable Cloud Security	Alpine Linux Local Security Checks	high
400363	Alpine: multiple xen packages: security update to 4.14.0-r0 (deprecated)	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	high
144794	XENMEM_aquire_resources Error Path DoS (XSA-334)	Nessus	Misc.	medium
143853	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2788-1)	Nessus	SuSE Local Security Checks	high
143707	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:2791-1)	Nessus	SuSE Local Security Checks	high
143685	SUSE SLES12 Security Update : xen (SUSE-SU-2020:2786-1)	Nessus	SuSE Local Security Checks	high
143637	SUSE SLED15 / SLES15 Security Update : xen (SUSE-SU-2020:2790-1)	Nessus	SuSE Local Security Checks	high
142854	GLSA-202011-06 : Xen: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	high
141278	Fedora 31 : xen (2020-d46fe34349)	Nessus	Fedora Local Security Checks	high
141270	Fedora 33 : xen (2020-306b84fd07)	Nessus	Fedora Local Security Checks	high
141168	openSUSE Security Update : xen (openSUSE-2020-1608)	Nessus	SuSE Local Security Checks	high
141102	Fedora 32 : xen (2020-f668e579be)	Nessus	Fedora Local Security Checks	high

Detections

Analytics

CVE-2020-25598

medium

Tenable Plugins

high

high

high

high

high

high

high

high

medium

high

high

high

high

high

high

high

high

high