| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Xen 4.1.x and 4.2.x, when the XSA-45 patch is in place, does not properly maintain references on pages stored for deferred cleanup, which allows local PV guest kernels to cause a denial of service (premature page free and hypervisor crash) or possibly gain privileges via unspecified vectors. |
| Use-after-free vulnerability in the libxl_list_cpupool function in the libxl toolstack library in Xen 4.2.x and 4.3.x, when running "under memory pressure," returns the original pointer when the realloc function fails, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors. |
| The outs instruction emulation in Xen 3.1.x, 4.2.x, 4.3.x, and earlier, when using FS: or GS: segment override, uses an uninitialized variable as a segment base, which allows local 64-bit PV guests to obtain sensitive information (hypervisor stack content) via unspecified vectors related to stale data in a segment register. |
| oxenstored in Xen 4.1.x, Xen 4.2.x, and xen-unstable does not properly consider the state of the Xenstore ring during read operations, which allows guest OS users to cause a denial of service (daemon crash and host-control outage, or memory consumption) or obtain sensitive control-plane data by leveraging guest administrative access. |
| The x86-64 kernel system-call functionality in Xen 4.1.2 and earlier, as used in Citrix XenServer 6.0.2 and earlier and other products; Oracle Solaris 11 and earlier; illumos before r13724; Joyent SmartOS before 20120614T184600Z; FreeBSD before 9.0-RELEASE-p3; NetBSD 6.0 Beta and earlier; Microsoft Windows Server 2008 R2 and R2 SP1 and Windows 7 Gold and SP1; and possibly other operating systems, when running on an Intel processor, incorrectly uses the sysret path in cases where a certain address is not a canonical address, which allows local users to gain privileges via a crafted application. NOTE: because this issue is due to incorrect use of the Intel specification, it should have been split into separate identifiers; however, there was some value in preserving the original mapping of the multi-codebase coordinated-disclosure effort to a single identifier. |
| Xen 3.4 through 4.2, and possibly earlier versions, does not properly synchronize the p2m and m2p tables when the set_p2m_entry function fails, which allows local HVM guest OS administrators to cause a denial of service (memory consumption and assertion failure), aka "Memory mapping failure DoS vulnerability." |
| The (1) domain_pirq_to_emuirq and (2) physdev_unmap_pirq functions in Xen 2.2 allows local guest OS administrators to cause a denial of service (Xen crash) via a crafted pirq value that triggers an out-of-bounds read. |
| The fbld instruction emulation in Xen 3.3.x through 4.3.x does not use the correct variable for the source effective address, which allows local HVM guests to obtain hypervisor stack information by reading the values used by the instruction. |
| Xen 3.4 through 4.2, and possibly earlier versions, allows local guest OS administrators to cause a denial of service (Xen infinite loop and physical CPU consumption) by setting a VCPU with an "inappropriate deadline." |
| The xlu_vif_parse_rate function in the libxlu library in Xen 4.2.x and 4.3.x allows local users to cause a denial of service (NULL pointer dereference) by using the "@" character as the VIF rate configuration. |
| The ocaml binding for the xc_vcpu_getaffinity function in Xen 4.2.x and 4.3.x frees certain memory that may still be intended for use, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors that trigger a (1) use-after-free or (2) double free. |
| Xen 4.3.x writes hypervisor mappings to certain shadow pagetables when live migration is performed on hosts with more than 5TB of RAM, which allows local 64-bit PV guests to read or write to invalid memory and cause a denial of service (crash). |
| Xen 4.0, and 4.1, when running a 64-bit PV guest on "older" AMD CPUs, does not properly protect against a certain AMD processor bug, which allows local guest OS users to cause a denial of service (host hang) via sequential execution of instructions across a non-canonical boundary, a different vulnerability than CVE-2012-0217. |
| The get_page_type function in xen/arch/x86/mm.c in Xen 4.2, when debugging is enabled, allows local PV or HVM guest administrators to cause a denial of service (assertion failure and hypervisor crash) via unspecified vectors related to a hypercall. |
| Xen 4.3.x and earlier does not properly handle certain errors, which allows local HVM guests to obtain hypervisor stack memory via a (1) port or (2) memory mapped I/O write or (3) other unspecified operations related to addresses without associated memory. |
| The graphical console in Xen 4.0, 4.1 and 4.2 allows local OS guest administrators to obtain sensitive host resource information via the qemu monitor. NOTE: this might be a duplicate of CVE-2007-0998. |
| Memory leak in Xen 4.2 and unstable allows local HVM guests to cause a denial of service (host memory consumption) by performing nested virtualization in a way that triggers errors that are not properly handled. |
| The AMD IOMMU support in Xen 4.2.x, 4.1.x, 3.3, and other versions, when using AMD-Vi for PCI passthrough, uses the same interrupt remapping table for the host and all guests, which allows guests to cause a denial of service by injecting an interrupt into other guests. |
| The xenlight library (libxl) in Xen 4.0.x through 4.2.x, when IOMMU is disabled, provides access to a busmastering-capable PCI passthrough device before the IOMMU setup is complete, which allows local HVM guest domains to gain privileges or cause a denial of service via a DMA instruction. |
| An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information. |
