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
The C+ mode offload emulation in the RTL8139 network card device model in QEMU, as used in Xen 4.5.x and earlier, allows remote attackers to read process heap memory via unspecified vectors.
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.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.
The PV superpage functionality in arch/x86/mm.c in Xen 3.4.0, 3.4.1, and 4.1.x through 4.6.x allows local PV guests to obtain sensitive information, cause a denial of service, gain privileges, or have unspecified other impact via a crafted page identifier (MFN) to the (1) MMUEXTMARKSUPER or (2) MMUEXTUNMARKSUPER sub-op in the HYPERVISORmmuextop hypercall or (3) unknown vectors related to page table updates.
Xen 3.3.x through 4.5.x does not properly restrict access to PCI MSI mask bits, which allows local x86 HVM guest users to cause a denial of service (unexpected interrupt and host crash) via unspecified vectors.
The libxl toolstack library in Xen 4.1.x through 4.6.x does not properly release mappings of files used as kernels and initial ramdisks when managing multiple domains in the same process, which allows attackers to cause a denial of service (memory and disk consumption) by starting domains.
The Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a denial of service (out-of-bounds write and guest crash) or possibly execute arbitrary code via the (1) FDCMDREADID, (2) FDCMDDRIVESPECIFICATIONCOMMAND, or other unspecified commands, aka VENOM.
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.
The x86 emulator in Xen 3.2.x through 4.5.x does not properly ignore segment overrides for instructions with register operands, which allows local guest users to obtain sensitive information, cause a denial of service (memory corruption), or possibly execute arbitrary code via unspecified vectors.
Use-after-free vulnerability in QEMU in Xen 4.5.x and earlier does not completely unplug emulated block devices, which allows local HVM guest users to gain privileges by unplugging a block device twice.
Heap-based buffer overflow in the IDE subsystem in QEMU, as used in Xen 4.5.x and earlier, when the container has a CDROM drive enabled, allows local guest users to execute arbitrary code on the host via unspecified ATAPI commands.
The modl2entry function in arch/x86/mm.c in Xen 3.4 through 4.6.x does not properly validate level 2 page table entries, which allows local PV guest administrators to gain privileges via a crafted superpage mapping.
Xen 4.3.x, 4.4.x, and 4.5.x, when using toolstack disaggregation, allows remote domains with partial management control to cause a denial of service (host lock) via unspecified domctl operations.
An issue was discovered in Xen through 4.14.x. There are evtchnreset() race conditions. Uses of EVTCHNOPreset (potentially by a guest on itself) or XENDOMCTLsoftreset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.
Stack-based buffer overflow in the xl command line utility in Xen 4.1.x through 4.5.x allows local guest administrators to gain privileges via a long configuration argument.
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.
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.
The paginginvlpg function in include/asm-x86/paging.h in Xen 3.3.x through 4.6.x, when using shadow mode paging or nested virtualization is enabled, allows local HVM guest users to cause a denial of service (host crash) via a non-canonical guest address in an INVVPID instruction, which triggers a hypervisor bug check.
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.
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.
x86: speculative vulnerability in 32bit SYSCALL path Due to an oversight in the very original Spectre/Meltdown security work (XSA-254), one entrypath performs its speculation-safety actions too late. In some configurations, there is an unprotected RET instruction which can be attacked with a variety of speculative attacks.
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 vgicv2tosgi 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.
QEMU, as used in Xen 3.3.x through 4.5.x, does not properly restrict access to PCI command registers, which might allow local HVM guest 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 XENDOMCTLmemorymapping 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).
GNTTABOPswapgrantref in Xen 4.2 through 4.5 does not check the grant table operation version, which allows local guest domains to cause a denial of service (NULL pointer dereference) via a hypercall without a GNTTABOPsetuptable or GNTTABOPsetversion.
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.