First published: Thu Nov 05 2015(Updated: )
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: ------------------- -> <a href="http://permalink.gmane.org/gmane.linux.kernel/2082332">http://permalink.gmane.org/gmane.linux.kernel/2082332</a> References: ----------- -> <a href="http://www.openwall.com/lists/oss-security/2015/11/10/1">http://www.openwall.com/lists/oss-security/2015/11/10/1</a>
Credit: cve@mitre.org cve@mitre.org cve@mitre.org
Affected Software | Affected Version | How to fix |
---|---|---|
Xen Xen | =4.3.0 | |
Xen Xen | =4.3.1 | |
Xen Xen | =4.3.2 | |
Xen Xen | =4.3.3 | |
Xen Xen | =4.3.4 | |
Xen Xen | =4.4.0 | |
Xen Xen | =4.4.1 | |
Xen Xen | =4.4.2 | |
Xen Xen | =4.4.3 | |
Xen Xen | =4.5.0 | |
Xen Xen | =4.5.1 | |
Xen Xen | =4.5.2 | |
Xen Xen | =4.6.0 | |
Xen Xen | =4.6.1 | |
Xen Xen | =4.6.2 | |
Xen Xen | =4.6.4 | |
Xen Xen | =4.6.5 | |
Oracle Solaris | =11.3 | |
Oracle VM VirtualBox | >=4.0.0<=4.0.34 | |
Oracle VM VirtualBox | >=4.1.0<=4.1.42 | |
Oracle VM VirtualBox | >=4.2.0<=4.2.34 | |
Oracle VM VirtualBox | >=4.3.0<=4.3.35 | |
Oracle VM VirtualBox | >=5.0.0<=5.0.13 | |
Linux Linux kernel | <=4.2.3 | |
Debian Debian Linux | =7.0 | |
Debian Debian Linux | =8.0 | |
Debian Debian Linux | =9.0 | |
Canonical Ubuntu Linux | =12.04 | |
Canonical Ubuntu Linux | =14.04 | |
Canonical Ubuntu Linux | =15.04 | |
debian/linux | 5.10.223-1 5.10.226-1 6.1.115-1 6.1.119-1 6.11.10-1 6.12.5-1 | |
debian/virtualbox | 7.0.20-dfsg-1 | |
debian/xen | 4.14.6-1 4.14.5+94-ge49571868d-1 4.17.3+10-g091466ba55-1~deb12u1 4.17.3+36-g54dacb5c02-1 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.