medium
4.7
CWE
399
Advisory Published
CVE Published
Updated

CVE-2015-8104

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: ------------------- -&gt; <a href="http://permalink.gmane.org/gmane.linux.kernel/2082332">http://permalink.gmane.org/gmane.linux.kernel/2082332</a> References: ----------- -&gt; <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 SoftwareAffected VersionHow to fix
Xen XAPI=4.3.0
Xen XAPI=4.3.1
Xen XAPI=4.3.2
Xen XAPI=4.3.3
Xen XAPI=4.3.4
Xen XAPI=4.4.0
Xen XAPI=4.4.1
Xen XAPI=4.4.2
Xen XAPI=4.4.3
Xen XAPI=4.5.0
Xen XAPI=4.5.1
Xen XAPI=4.5.2
Xen XAPI=4.6.0
Xen XAPI=4.6.1
Xen XAPI=4.6.2
Xen XAPI=4.6.4
Xen XAPI=4.6.5
Oracle Solaris and Zettabyte File System (ZFS)=11.3
Oracle VirtualBox>=4.0.0<=4.0.34
Oracle VirtualBox>=4.1.0<=4.1.42
Oracle VirtualBox>=4.2.0<=4.2.34
Oracle VirtualBox>=4.3.0<=4.3.35
Oracle VirtualBox>=5.0.0<=5.0.13
Linux Kernel<=4.2.3
Debian Linux=7.0
Debian Linux=8.0
Debian Linux=9.0
Ubuntu=12.04
Ubuntu=14.04
Ubuntu=15.04
debian/linux
5.10.223-1
5.10.234-1
6.1.129-1
6.1.128-1
6.12.21-1
6.12.22-1
debian/virtualbox
7.0.20-dfsg-1.2
debian/xen
4.14.6-1
4.14.5+94-ge49571868d-1
4.17.5+23-ga4e5191dc0-1+deb12u1
4.17.5+23-ga4e5191dc0-1
4.20.0-1

Remedy

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cbdb967af3d54993f5814f1cee0ed311a055377d

Remedy

http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html

Remedy

http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html

Remedy

http://xenbits.xen.org/xsa/advisory-156.html

Remedy

https://github.com/torvalds/linux/commit/cbdb967af3d54993f5814f1cee0ed311a055377d

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Read MoreStart Free Trial

Reference Links

Frequently Asked Questions

  • What is the severity of CVE-2015-8104?

    CVE-2015-8104 has a high severity level due to its potential to cause Denial of Service (DoS) by exploiting the Xen hypervisor.

  • How do I fix CVE-2015-8104?

    To remediate CVE-2015-8104, upgrade to patched versions of the affected Xen hypervisor or related distributions as specified in security advisories.

  • Which software versions are affected by CVE-2015-8104?

    CVE-2015-8104 affects Xen versions from 4.3.0 to 4.6.5 and certain versions of Oracle VM VirtualBox and Debian Linux.

  • What is the impact of CVE-2015-8104 on system performance?

    Exploitation of CVE-2015-8104 can lead to significant performance degradation by preventing the use of physical CPU resources.

  • Who can exploit CVE-2015-8104?

    This vulnerability can be exploited by a malicious HVM guest administrator within the Xen hypervisor environment.

Company

Resources

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2025 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203