Xen 4.x, when using Intel VT-d for a bus mastering capable PCI device, does not properly check the source when accessing a bridge device's interrupt remapping table entries for MSI interrupts, which allows local guest domains to cause a denial of service (interrupt injection) via unspecified vectors.

Xen 4.2.x, 4.1.x, and earlier, when the hypervisor is running "under memory pressure" and the Xen Security Module (XSM) is enabled, uses the wrong ordering of operations when extending the per-domain event channel tracking table, which causes a use-after-free and allows local guest kernels to inject arbitrary events and gain privileges via unspecified vectors.

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.

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.

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 guest_physmap_mark_populate_on_demand function in Xen 4.2 and earlier does not properly unlock the subject GFNs when checking if they are in use, which allows local guest HVM administrators to cause a denial of service (hang) via unspecified vectors.

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.x, when downgrading the grant table version, does not properly remove the status page from the tracking list when freeing the page, which allows local guest OS administrators to cause a denial of service (hypervisor crash) via unspecified vectors.

The XENMEM_exchange handler in Xen 4.2 and earlier does not properly check the memory address, which allows local PV guest OS administrators to cause a denial of service (crash) or possibly gain privileges via unspecified vectors that overwrite memory in the hypervisor reserved range.

The (1) XENMEM_decrease_reservation, (2) XENMEM_populate_physmap, and (3) XENMEM_exchange hypercalls in Xen 4.2 and earlier allow local guest administrators to cause a denial of service (long loop and hang) via a crafted extent_order value.