Xen 4.5.x through 4.7.x do not implement Supervisor Mode Access Prevention (SMAP) whitelisting in 32-bit exception and event delivery, which allows local 32-bit PV guest OS kernels to cause a denial of service (hypervisor and VM crash) by triggering a safety check.
An issue was discovered in Xen 4.8.x through 4.10.x allowing x86 PVH guest OS users to cause a denial of service (NULL pointer dereference and hypervisor crash) by leveraging the mishandling of configurations that lack a Local APIC.
An issue was discovered in Xen through 4.10.x allowing x86 PV guest OS users to cause a denial of service (host OS CPU hang) via non-preemptable L3/L4 pagetable freeing.
In Xen 4.10, new infrastructure was introduced as part of an overhaul to how MSR emulation happens for guests. Unfortunately, one tracking structure isn't freed when a vcpu is destroyed. This allows guest OS administrators to cause a denial of service (host OS memory consumption) by rebooting many times.
The compat_iret function in Xen 3.1 through 4.5 iterates the wrong way through a loop, which allows local 32-bit PV guest administrators to cause a denial of service (large loop and system hang) via a hypercall_iret call with EFLAGS.VM set.
Xen 3.3.x through 4.5.x does not properly restrict write access to the host MSI message data field, which allows local x86 HVM guest administrators to cause a denial of service (host interrupt handling confusion) via vectors related to qemu and accessing spanning multiple fields.
Xen 3.3.x through 4.5.x enables logging for PCI MSI-X pass-through error messages, which allows local x86 HVM guests to cause a denial of service (host disk consumption) via certain invalid operations.
The XEN_DOMCTL_memory_mapping hypercall in Xen 3.2.x through 4.5.x, when using a PCI passthrough device, is not preemptible, which allows local x86 HVM domain users to cause a denial of service (host CPU consumption) via a crafted request to the device model (qemu-dm).
Xen 3.3.x through 4.5.x and the Linux kernel through 3.19.1 do not properly restrict access to PCI command registers, which might allow local guest OS users to cause a denial of service (non-maskable interrupt and host crash) by disabling the (1) memory or (2) I/O decoding for a PCI Express device and then accessing the device, which triggers an Unsupported Request (UR) response.
The vgic_v2_to_sgi function in arch/arm/vgic-v2.c in Xen 4.5.x, when running on ARM hardware with general interrupt controller (GIC) version 2, allows local guest users to cause a denial of service (host crash) by writing an invalid value to the GICD.SGIR register.
The acceleration support for the "REP MOVS" instruction in Xen 4.4.x, 3.2.x, and earlier lacks properly bounds checking for memory mapped I/O (MMIO) emulated in the hypervisor, which allows local HVM guests to cause a denial of service (host crash) via unspecified vectors.
An issue was discovered in Xen 4.11.x allowing x86 guest OS users to cause a denial of service (host OS hang) because the p2m lock remains unavailable indefinitely in certain error conditions.
An issue was discovered in Xen through 4.14.x. Nodes in xenstore have an ownership. In oxenstored, a owner could give a node away. However, node ownership has quota implications. Any guest can run another guest out of quota, or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable.
An issue was discovered in Xen through 4.14.x. Xenstored and guests communicate via a shared memory page using a specific protocol. When a guest violates this protocol, xenstored will drop the connection to that guest. Unfortunately, this is done by just removing the guest from xenstored's internal management, resulting in the same actions as if the guest had been destroyed, including sending an @releaseDomain event. @releaseDomain events do not say that the guest has been removed. All watchers of this event must look at the states of all guests to find the guest that has been removed. When an @releaseDomain is generated due to a domain xenstored protocol violation, because the guest is still running, the watchers will not react. Later, when the guest is actually destroyed, xenstored will no longer have it stored in its internal data base, so no further @releaseDomain event will be sent. This can lead to a zombie domain; memory mappings of that guest's memory will not be removed, due to the missing event. This zombie domain will be cleaned up only after another domain is destroyed, as that will trigger another @releaseDomain event. If the device model of the guest that violated the Xenstore protocol is running in a stub-domain, a use-after-free case could happen in xenstored, after having removed the guest from its internal data base, possibly resulting in a crash of xenstored. A malicious guest can block resources of the host for a period after its own death. Guests with a stub domain device model can eventually crash xenstored, resulting in a more serious denial of service (the prevention of any further domain management operations). Only the C variant of Xenstore is affected; the Ocaml variant is not affected. Only HVM guests with a stubdom device model can cause a serious DoS.
Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host panic) by sending an asynchronous abort.
Xen through 4.7.x allows local ARM guest OS users to cause a denial of service (host crash) via vectors involving an asynchronous abort while at HYP.