| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The do_block_io_op function in (1) drivers/xen/blkback/blkback.c and (2) drivers/xen/blktap/blktap.c in Xen before 3.4.0 for the Linux kernel 2.6.18, and possibly other versions, allows guest OS users to cause a denial of service (infinite loop and CPU consumption) via a large production request index to the blkback or blktap back-end drivers. NOTE: some of these details are obtained from third party information. |
| PHYSDEVOP_map_pirq in Xen 4.1 and 4.2 and Citrix XenServer 6.0.2 and earlier allows local HVM guest OS kernels to cause a denial of service (host crash) and possibly read hypervisor or guest memory via vectors related to a missing range check of map->index. |
| The set_debugreg hypercall in include/asm-x86/debugreg.h in Xen 4.0, 4.1, and 4.2, and Citrix XenServer 6.0.2 and earlier, when running on x86-64 systems, allows local OS guest users to cause a denial of service (host crash) by writing to the reserved bits of the DR7 debug control register. |
| Unspecified vulnerability in Citrix XenMobile Device Manager server (formerly Zenprise Device Manager server) 8.5, 8.6, and MDM 8.0.1 allows remote attackers to obtain sensitive information via unknown vectors. |
| The NDVM in Citrix XenClient XT before 2.1.3 and 3.x before 3.1.4 allows remote attackers to execute arbitrary commands by using the UIVM to create a network connection. |
| The physdev_get_free_pirq hypercall in arch/x86/physdev.c in Xen 4.1.x and Citrix XenServer 6.0.2 and earlier uses the return value of the get_free_pirq function as an array index without checking that the return value indicates an error, which allows guest OS users to cause a denial of service (invalid memory write and host crash) and possibly gain privileges via unspecified vectors. |
| 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 GNTTABOP_swap_grant_ref sub-operation in the grant table hypercall in Xen 4.2 and Citrix XenServer 6.0.2 allows local guest kernels or administrators to cause a denial of service (host crash) and possibly gain privileges via a crafted grant reference that triggers a write to an arbitrary hypervisor memory location. |
| Citrix XenServer 5.0 Update 2 and earlier, and 5.5 Update 1 and earlier, when using a pvops kernel, allows guest users to cause a denial of service in the host via unspecified vectors that trigger "incorrectly set flags." |
| Citrix XenDesktop 7.0, when upgraded from XenDesktop 5.x, does not properly enforce policy rule permissions, which allows remote attackers to bypass intended restrictions. |
| Array index error in the HVMOP_set_mem_access handler in Xen 4.1 allows local HVM guest OS administrators to cause a denial of service (crash) or obtain sensitive information 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. |
| Citrix XenDesktop Virtual Desktop Agent (VDA) 5.6.x before 5.6.200, when making changes to the server-side policy that control USB redirection, does not propagate changes to the VDA, which allows authenticated users to retain access to the USB device. |
| Xen 4.1 before 4.1.1 and 4.0 before 4.0.2, when using PCI passthrough on Intel VT-d chipsets that do not have interrupt remapping, allows guest OS users to gain host OS privileges by "using DMA to generate MSI interrupts by writing to the interrupt injection registers." |
| The backend driver in Xen 3.x allows guest OS users to cause a denial of service via a kernel thread leak, which prevents the device and guest OS from being shut down or create a zombie domain, causes a hang in zenwatch, or prevents unspecified xm commands from working properly, related to (1) netback, (2) blkback, or (3) blktap. |
| Unspecified vulnerability in Citrix XenServer 5.0 Update 3 and earlier, and 5.5, allows local users to bypass authentication and execute unspecified Xen API (XAPI) calls via unknown vectors. |
| tools/libxc/xc_dom_bzimageloader.c in Xen 3.2, 3.3, 4.0, and 4.1 allows local users to cause a denial of service (management software infinite loop and management domain resource consumption) via unspecified vectors related to "Lack of error checking in the decompression loop." |
| xend in Xen 3.3.0 does not properly restrict a guest VM's write access within the /local/domain xenstore directory tree, which allows guest OS users to cause a denial of service and possibly have unspecified other impact by writing to (1) console/tty, (2) console/limit, or (3) image/device-model-pid. NOTE: this issue exists because of erroneous set_permissions calls in the fix for CVE-2008-4405. |
| Static code injection vulnerability in config/writeconfig.php in the sample code in the XenServer Resource Kit in Citrix XenCenterWeb allows remote attackers to inject arbitrary PHP code into include/config.ini.php via the pool1 parameter. NOTE: some of these details are obtained from third party information. |
| Multiple cross-site scripting (XSS) vulnerabilities in sample code in the XenServer Resource Kit in Citrix XenCenterWeb allow remote attackers to inject arbitrary web script or HTML via the (1) username parameter to config/edituser.php; (2) location, (3) sessionid, and (4) vmname parameters to console.php; (5) vmrefid and (6) vmname parameters to forcerestart.php; and (7) vmname and (8) vmrefid parameters to forcesd.php. NOTE: some of these details are obtained from third party information. |
