| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 IRQ setup in Xen 4.2.x and 4.3.x, when using device passthrough and configured to support a large number of CPUs, frees certain memory that may still be intended for use, which allows local guest administrators to cause a denial of service (memory corruption and hypervisor crash) and possibly execute arbitrary code via vectors related to an out-of-memory error that triggers a (1) use-after-free or (2) double free. |
| Xen in the Linux kernel, when running a guest on a host without hardware assisted paging (HAP), allows guest users to cause a denial of service (invalid pointer dereference and hypervisor crash) via the SAHF instruction. |
| (1) TMEMC_SAVE_GET_CLIENT_WEIGHT, (2) TMEMC_SAVE_GET_CLIENT_CAP, (3) TMEMC_SAVE_GET_CLIENT_FLAGS and (4) TMEMC_SAVE_END in the Transcendent Memory (TMEM) in Xen 4.0, 4.1, and 4.2 allow local guest OS users to cause a denial of service (NULL pointer dereference or memory corruption and host crash) or possibly have other unspecified impacts via a NULL client id. |
| XENMEM_populate_physmap in Xen 4.0, 4.1, and 4.2, and Citrix XenServer 6.0.2 and earlier, when translating paging mode is not used, allows local PV OS guest kernels to cause a denial of service (BUG triggered and host crash) via invalid flags such as MEMF_populate_on_demand. |
| The Intel VT-d Interrupt Remapping engine in Xen 3.3.x through 4.3.x allows local guests to cause a denial of service (kernel panic) via a malformed Message Signaled Interrupt (MSI) from a PCI device that is bus mastering capable that triggers a System Error Reporting (SERR) Non-Maskable Interrupt (NMI). |
| Multiple HVM control operations in Xen 3.4 through 4.2 allow local HVM guest OS administrators to cause a denial of service (physical CPU consumption) via a large input. |
| Xen 4.0 and 4.1 allows local HVM guest OS kernels to cause a denial of service (domain 0 VCPU hang and kernel panic) by modifying the physical address space in a way that triggers excessive shared page search time during the p2m teardown. |
| The do_tmem_destroy_pool function in the Transcendent Memory (TMEM) in Xen 4.0, 4.1, and 4.2 does not properly validate pool ids, which allows local guest OS users to cause a denial of service (memory corruption and host crash) or execute arbitrary code via unspecified vectors. NOTE: this issue was originally published as part of CVE-2012-3497, which was too general; CVE-2012-3497 has been SPLIT into this ID and others. |
| The (1) tmemc_save_get_next_page and (2) tmemc_save_get_next_inv functions and the (3) TMEMC_SAVE_GET_POOL_UUID sub-operation in the Transcendent Memory (TMEM) in Xen 4.0, 4.1, and 4.2 "do not check incoming guest output buffer pointers," which allows local guest OS users to cause a denial of service (memory corruption and host crash) or execute arbitrary code via unspecified vectors. NOTE: this issue was originally published as part of CVE-2012-3497, which was too general; CVE-2012-3497 has been SPLIT into this ID and others. |
| Multiple unspecified vulnerabilities in the Elf parser (libelf) in Xen 4.2.x and earlier allow local guest administrators with certain permissions to have an unspecified impact via a crafted kernel, related to "other problems" that are not CVE-2013-2194 or CVE-2013-2195. |
| The Elf parser (libelf) in Xen 4.2.x and earlier allow local guest administrators with certain permissions to have an unspecified impact via a crafted kernel, related to "pointer dereferences" involving unexpected calculations. |
| The PV domain builder in Xen 4.2 and earlier does not validate the size of the kernel or ramdisk (1) before or (2) after decompression, which allows local guest administrators to cause a denial of service (domain 0 memory consumption) via a crafted (a) kernel or (b) ramdisk. |
| 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 do_physdev_op function in Xen 4.1.5, 4.1.6.1, 4.2.2 through 4.2.3, and 4.3.x does not properly restrict access to the (1) PHYSDEVOP_prepare_msix and (2) PHYSDEVOP_release_msix operations, which allows local PV guests to cause a denial of service (host or guest malfunction) or possibly gain privileges via unspecified vectors. |
| 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 4.2.x, 4.1.x, and 4.0, when using Intel VT-d for PCI passthrough, does not properly configure VT-d when supporting a device that is behind a legacy PCI Bridge, which allows local guests to cause a denial of service to other guests by injecting an interrupt. |
| Xen 3.0.3 through 4.1.x (possibly 4.1.6.1), 4.2.x (possibly 4.2.3), and 4.3.x (possibly 4.3.1) does not properly prevent access to hypercalls, which allows local guest users to gain privileges via a crafted application running in ring 1 or 2. |
| The XEN_DOMCTL_getmemlist hypercall in Xen 3.4.x through 4.3.x (possibly 4.3.1) does not always obtain the page_alloc_lock and mm_rwlock in the same order, which allows local guest administrators to cause a denial of service (host deadlock). |
| Xen 4.2.x and 4.3.x, when nested virtualization is disabled, does not properly check the emulation paths for (1) VMLAUNCH and (2) VMRESUME, which allows local HVM guest users to cause a denial of service (host crash) via unspecified vectors related to "guest VMX instruction execution." |
