National Vulnerability Database

National Vulnerability Database

National Vulnerability
Database

Search Results (Refine Search)

Search Parameters:
  • Contains Software Flaws (CVE)
  • CPE Product Version: cpe:/o:xen:xen:4.6.3::~~~~arm~
There are 91 matching records.
Displaying matches 1 through 20.
Vuln ID Summary CVSS Severity
CVE-2020-11743

An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of a bad error path in GNTTABOP_map_grant. Grant table operations are expected to return 0 for success, and a negative number for errors. Some misplaced brackets cause one error path to return 1 instead of a negative value. The grant table code in Linux treats this condition as success, and proceeds with incorrectly initialised state. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to map a grant, it hits the incorrect error path. This will crash a Linux based dom0 or backend domain.

Published: April 14, 2020; 09:15:12 AM -04:00
V3.1: 5.5 MEDIUM
    V2: 2.1 LOW
CVE-2020-11742

An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service because of bad continuation handling in GNTTABOP_copy. Grant table operations are expected to return 0 for success, and a negative number for errors. The fix for CVE-2017-12135 introduced a path through grant copy handling where success may be returned to the caller without any action taken. In particular, the status fields of individual operations are left uninitialised, and may result in errant behaviour in the caller of GNTTABOP_copy. A buggy or malicious guest can construct its grant table in such a way that, when a backend domain tries to copy a grant, it hits the incorrect exit path. This returns success to the caller without doing anything, which may cause crashes or other incorrect behaviour.

Published: April 14, 2020; 09:15:12 AM -04:00
V3.1: 5.5 MEDIUM
    V2: 2.1 LOW
CVE-2020-11741

An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (with active profiling) to obtain sensitive information about other guests, cause a denial of service, or possibly gain privileges. For guests for which "active" profiling was enabled by the administrator, the xenoprof code uses the standard Xen shared ring structure. Unfortunately, this code did not treat the guest as a potential adversary: it trusts the guest not to modify buffer size information or modify head / tail pointers in unexpected ways. This can crash the host (DoS). Privilege escalation cannot be ruled out.

Published: April 14, 2020; 09:15:12 AM -04:00
V3.1: 8.8 HIGH
    V2: 6.9 MEDIUM
CVE-2020-11740

An issue was discovered in xenoprof in Xen through 4.13.x, allowing guest OS users (without active profiling) to obtain sensitive information about other guests. Unprivileged guests can request to map xenoprof buffers, even if profiling has not been enabled for those guests. These buffers were not scrubbed.

Published: April 14, 2020; 09:15:12 AM -04:00
V3.1: 5.5 MEDIUM
    V2: 2.1 LOW
CVE-2020-11739

An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.

Published: April 14, 2020; 09:15:12 AM -04:00
V3.1: 7.8 HIGH
    V2: 6.9 MEDIUM
CVE-2019-19577

An issue was discovered in Xen through 4.12.x allowing x86 AMD HVM guest OS users to cause a denial of service or possibly gain privileges by triggering data-structure access during pagetable-height updates. When running on AMD systems with an IOMMU, Xen attempted to dynamically adapt the number of levels of pagetables (the pagetable height) in the IOMMU according to the guest's address space size. The code to select and update the height had several bugs. Notably, the update was done without taking a lock which is necessary for safe operation. A malicious guest administrator can cause Xen to access data structures while they are being modified, causing Xen to crash. Privilege escalation is thought to be very difficult but cannot be ruled out. Additionally, there is a potential memory leak of 4kb per guest boot, under memory pressure. Only Xen on AMD CPUs is vulnerable. Xen running on Intel CPUs is not vulnerable. ARM systems are not vulnerable. Only systems where guests are given direct access to physical devices are vulnerable. Systems which do not use PCI pass-through are not vulnerable. Only HVM guests can exploit the vulnerability. PV and PVH guests cannot. All versions of Xen with IOMMU support are vulnerable.

Published: December 11, 2019; 01:16:19 PM -05:00
V3.1: 7.2 HIGH
    V2: 7.2 HIGH
CVE-2019-19579

An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device (and assignable-add is not used), because of an incomplete fix for CVE-2019-18424. XSA-302 relies on the use of libxl's "assignable-add" feature to prepare devices to be assigned to untrusted guests. Unfortunately, this is not considered a strictly required step for device assignment. The PCI passthrough documentation on the wiki describes alternate ways of preparing devices for assignment, and libvirt uses its own ways as well. Hosts where these "alternate" methods are used will still leave the system in a vulnerable state after the device comes back from a guest. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable.

Published: December 04, 2019; 05:15:15 PM -05:00
V3.1: 6.8 MEDIUM
    V2: 7.2 HIGH
CVE-2019-18424

An issue was discovered in Xen through 4.12.x allowing attackers to gain host OS privileges via DMA in a situation where an untrusted domain has access to a physical device. This occurs because passed through PCI devices may corrupt host memory after deassignment. When a PCI device is assigned to an untrusted domain, it is possible for that domain to program the device to DMA to an arbitrary address. The IOMMU is used to protect the host from malicious DMA by making sure that the device addresses can only target memory assigned to the guest. However, when the guest domain is torn down, or the device is deassigned, the device is assigned back to dom0, thus allowing any in-flight DMA to potentially target critical host data. An untrusted domain with access to a physical device can DMA into host memory, leading to privilege escalation. Only systems where guests are given direct access to physical devices capable of DMA (PCI pass-through) are vulnerable. Systems which do not use PCI pass-through are not vulnerable.

Published: October 31, 2019; 10:15:12 AM -04:00
V3.1: 6.8 MEDIUM
    V2: 6.9 MEDIUM
CVE-2019-18422

An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service or gain privileges by leveraging the erroneous enabling of interrupts. Interrupts are unconditionally unmasked in exception handlers. When an exception occurs on an ARM system which is handled without changing processor level, some interrupts are unconditionally enabled during exception entry. So exceptions which occur when interrupts are masked will effectively unmask the interrupts. A malicious guest might contrive to arrange for critical Xen code to run with interrupts erroneously enabled. This could lead to data corruption, denial of service, or possibly even privilege escalation. However a precise attack technique has not been identified.

Published: October 31, 2019; 10:15:10 AM -04:00
V3.1: 8.8 HIGH
    V2: 8.5 HIGH
CVE-2019-17349

An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a LoadExcl or StoreExcl operation.

Published: October 07, 2019; 09:15:11 PM -04:00
V3.1: 5.5 MEDIUM
    V2: 4.9 MEDIUM
CVE-2019-17348

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service because of an incompatibility between Process Context Identifiers (PCID) and shadow-pagetable switching.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 6.5 MEDIUM
    V2: 4.9 MEDIUM
CVE-2019-17347

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges because a guest can manipulate its virtualised %cr4 in a way that is incompatible with Linux (and possibly other guest kernels).

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 7.8 HIGH
    V2: 4.6 MEDIUM
CVE-2019-17346

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges because of an incompatibility between Process Context Identifiers (PCID) and TLB flushes.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 8.8 HIGH
    V2: 7.2 HIGH
CVE-2019-17344

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service by leveraging a long-running operation that exists to support restartability of PTE updates.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 6.5 MEDIUM
    V2: 4.9 MEDIUM
CVE-2019-17343

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging incorrect use of the HVM physmap concept for PV domains.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 6.8 MEDIUM
    V2: 4.6 MEDIUM
CVE-2019-17342

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging a race condition that arose when XENMEM_exchange was introduced.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 7.0 HIGH
    V2: 4.4 MEDIUM
CVE-2019-17341

An issue was discovered in Xen through 4.11.x allowing x86 PV guest OS users to cause a denial of service or gain privileges by leveraging a page-writability race condition during addition of a passed-through PCI device.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 7.8 HIGH
    V2: 6.9 MEDIUM
CVE-2019-17340

An issue was discovered in Xen through 4.11.x allowing x86 guest OS users to cause a denial of service or gain privileges because grant-table transfer requests are mishandled.

Published: October 07, 2019; 09:15:10 PM -04:00
V3.1: 8.8 HIGH
    V2: 6.1 MEDIUM
CVE-2019-17351

An issue was discovered in drivers/xen/balloon.c in the Linux kernel before 5.2.3, as used in Xen through 4.12.x, allowing guest OS users to cause a denial of service because of unrestricted resource consumption during the mapping of guest memory, aka CID-6ef36ab967c7.

Published: October 07, 2019; 08:15:10 PM -04:00
V3.1: 6.5 MEDIUM
    V2: 4.9 MEDIUM
CVE-2019-17350

An issue was discovered in Xen through 4.12.x allowing Arm domU attackers to cause a denial of service (infinite loop) involving a compare-and-exchange operation.

Published: October 07, 2019; 08:15:10 PM -04:00
V3.1: 5.5 MEDIUM
    V2: 4.9 MEDIUM