It was found that a malicious HVM guest administrator can cause DoS, specifically prevent use of physical CPU for significant, perhaps indefinite period. When a benign exception occurs while delivering another benign exception, it is architecturally specified that these would be delivered sequentially. There are, however, cases where this results in an infinite loop inside the CPU, which (in the virtualized case) can be broken only by intercepting delivery of the respective exception.
When a guest sets up a hardware breakpoint covering a data structure involved in delivering #DB (Debug Exception), upon completion of the delivery of the first exception another #DB will need to be delivered. The effects slightly differ depending on further guest characteristics:
Guests running in 32-bit mode would be expected to sooner or later encounter another fault due to the stack pointer decreasing during each iteration of the loop. The most likely case would be #PF (Page Fault) due to running into unmapped virtual space. However, an infinite loop cannot be excluded (e.g. when the guest is running with paging disabled).
Guests running in long mode, but not using the IST (Interrupt Stack Table) feature for the IDT entry corresponding to #DB would behave similarly to guests running in 32-bit mode, just that the larger virtual address space allows for a much longer loop. The loop can't, however, be infinite, as eventually the stack pointer would move into non-canonical address space, causing #SS (Stack Fault) instead.
Guests running in long mode and using the IST for the IDT entry corresponding to #DB would enter an infinite loop, as the stack pointer wouldn't change between #DB instances.
If a host watchdog (Xen or dom0) is in use, this can lead to a watchdog timeout and consequently a reboot of the host. If another, innocent, guest, is configured with a watchdog, this issue can lead to a reboot of such a guest.
A privileged user inside guest could use this flaw to crash the host kernel resulting in DoS.
For KVM virtualisation, it only affects the AMD processor support, as for Intel it already intercepts the #DB exception.
Upstream KVM patch: ------------------- -> http://permalink.gmane.org/gmane.linux.kernel/2082332
References: ----------- -> http://www.openwall.com/lists/oss-security/2015/11/10/1
Xen 4.6.x, 4.5.x, 4.4.x, 4.3.x, and earlier do not initialize x86 FPU stack and XMM registers when XSAVE/XRSTOR are not used to manage guest extended register state, which allows local guest domains to obtain sensitive information from other domains via unspecified vectors.
Buffer overflow in hw/pt-msi.c in Xen 4.6.x and earlier, when using the qemu-xen-traditional (aka qemu-dm) device model, allows local x86 HVM guest administrators to gain privileges by leveraging a system with access to a passed-through MSI-X capable physical PCI device and MSI-X table entries, related to a "write path."
It was found that a guest can DoS a host by triggering an infinite loop in microcode. If a guest in 32-bit mode enabled alignment exceptions, puts the exception handler in ring 3, and then triggers an alignment exception with an unaligned stack, then the microcode will enter an infinite loop. Because there's no instruction boundary the core never receives another interrupt (including SMIs). The host kernel panics pretty quickly due to the effects.
A privileged user inside guest could use this flaw to crash the host kernel resulting in DoS.
Upstream KVM patch: ------------------- -> http://permalink.gmane.org/gmane.linux.kernel/2082329
References: ----------- -> http://www.openwall.com/lists/oss-security/2015/11/10/1
The PV pagetable code in arch/x86/mm.c in Xen 4.7.x and earlier allows local 32-bit PV guest OS administrators to gain host OS privileges by leveraging fast-paths for updating pagetable entries.
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.
The p2mteardown function in arch/arm/p2m.c in Xen 4.4.x through 4.6.x allows local guest OS users with access to the driver domain to cause a denial of service (NULL pointer dereference and host OS crash) by creating concurrent domains and holding references to them, related to VMID exhaustion.
The libxl device-handling in Xen through 4.6.x allows local guest OS users with access to the driver domain to cause a denial of service (management tool confusion) by manipulating information in the backend directories in xenstore.
The libxl device-handling in Xen 4.6.x and earlier allows local OS guest administrators to cause a denial of service (resource consumption or management facility confusion) or gain host OS privileges by manipulating information in guest controlled areas of xenstore.
The guestwalktables function in arch/x86/mm/guestwalk.c in Xen 4.6.x and earlier does not properly handle the Page Size (PS) page table entry bit at the L4 and L3 page table levels, which might allow local guest OS users to gain privileges via a crafted mapping of memory.
The fpufxrstor function in arch/x86/i387.c in Xen 4.x does not properly handle writes to the hardware FSW.ES bit when running on AMD64 processors, which allows local guest OS users to obtain sensitive register content information from another guest by leveraging pending exception and mask bits. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-2076.
Xen 4.6.x and earlier allows local guest administrators to cause a denial of service (host reboot) via vectors related to multiple mappings of MMIO pages with different cachability settings.
VMX in Xen 4.6.x and earlier, when using an Intel or Cyrix CPU, allows local HVM guest users to cause a denial of service (guest crash) via vectors related to a non-canonical RIP.
Memory leak in Xen 3.3 through 4.8.x allows guest OS users to cause a denial of service (ARM or x86 AMD host OS memory consumption) by continually rebooting, because certain cleanup is skipped if no pass-through device was ever assigned, aka XSA-207.
An issue was discovered in Xen 4.5.x through 4.9.x. The function gnttabcacheflush handles GNTTABOPcacheflush grant table operations. It checks to see if the calling domain is the owner of the page that is to be operated on. If it is not, the owner's grant table is checked to see if a grant mapping to the calling domain exists for the page in question. However, the function does not check to see if the owning domain actually has a grant table or not. Some special domains, such as DOMIDXEN, DOMIDIO and DOMIDCOW are created without grant tables. Hence, if gnttabcacheflush operates on a page owned by these special domains, it will attempt to dereference a NULL pointer in the domain struct.
Xen maintains the GTF{read,writ}ing bits as appropriate, to inform the guest that a grant is in use. A guest is expected not to modify the grant details while it is in use, whereas the guest is free to modify/reuse the grant entry when it is not in use. Under some circumstances, Xen will clear the status bits too early, incorrectly informing the guest that the grant is no longer in use. A guest may prematurely believe that a granted frame is safely private again, and reuse it in a way which contains sensitive information, while the domain on the far end of the grant is still using the grant. Xen 4.9, 4.8, 4.7, 4.6, and 4.5 are affected.
Xen through 4.8.x does not validate a vCPU array index upon the sending of an SGI, which allows guest OS users to cause a denial of service (hypervisor crash), aka XSA-225.
The vCPU context-switch implementation in Xen through 4.8.x improperly interacts with the Memory Protection Extensions (MPX) and Protection Key (PKU) features, which makes it easier for guest OS users to defeat ASLR and other protection mechanisms, aka XSA-220.
Xen through 4.6.x on 64-bit platforms mishandles a failsafe callback, which might allow PV guest OS users to execute arbitrary code on the host OS, aka XSA-215.