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

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox prior to 3.2.20, 4.0.22, 4.1.30, 4.2.22, and 4.3.6 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Core.

Unspecified vulnerability in the VirtualBox component in Oracle Virtualization 4.0, 4.1, and 4.2 allows local users to affect integrity and availability via unknown vectors related to Core. NOTE: The previous information was obtained from the January 2013 Oracle CPU. Oracle has not commented on claims from another vendor that this issue is related to an incorrect comparison in the vgadrawtext function in Devices/Graphics/DevVGA.cpp, which can cause VirtualBox to "draw more lines than necessary."

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 4.1.34, before 4.2.26, and before 4.3.14 allows local users to affect availability via vectors related to Graphics driver (WDDM) for Windows guests.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 3.2.24, 4.0.26, 4.1.34, 4.2.26, and 4.3.12 allows local users to affect confidentiality via unknown vectors related to Core.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 3.2.24, 4.0.26, 4.1.34, 4.2.26, and 4.3.12 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Core.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 3.2.24, 4.0.26, 4.1.34, 4.2.26, and 4.3.14, when running on Windows, allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Core, a different vulnerability than CVE-2014-4261.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 3.2.24, 4.0.26, 4.1.34, 4.2.26, and 4.3.12 allows local users to affect integrity and availability via unknown vectors related to Core, a different vulnerability than CVE-2014-2486.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 3.2.24, 4.0.26, 4.1.34, 4.2.26, and 4.3.12 allows local users to affect integrity and availability via unknown vectors related to Core, a different vulnerability than CVE-2014-2477.

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

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 4.0.34, 4.1.42, 4.2.34, 4.3.32, and 5.0.8, when a VM has the Remote Display feature (RDP) enabled, allows remote attackers to affect availability via unknown vectors related to Core.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox prior to 4.0.34, 4.1.42, 4.2.34, 4.3.32, and 5.0.8, when using a Windows guest, allows local users to affect availability via unknown vectors related to Core.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox prior to 4.0.32, 4.1.40, 4.2.32, and 4.3.30 allows local users to affect confidentiality, integrity, and availability via unknown vectors related to Core.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox prior to 3.2.26, 4.0.28, 4.1.36, and 4.2.28 allows local users to affect availability via unknown vectors related to Core, a different vulnerability than CVE-2015-0377.

Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox prior to 3.2.26, 4.0.28, 4.1.36, and 4.2.28 allows local users to affect availability via unknown vectors related to Core, a different vulnerability than CVE-2015-0418.