-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT External Security Bulletin Redistribution
Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156
16 November 2015
AusCERT Security Bulletin Summary
Operating System: Xen
UNIX variants (UNIX, Linux, OSX)
Impact/Access: Denial of Service -- Existing Account
CVE Names: CVE-2015-8104 CVE-2015-5307
- --------------------------BEGIN INCLUDED TEXT--------------------
- -----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2015-5307,CVE-2015-8104 / XSA-156
x86: CPU lockup during exception delivery
UPDATES IN VERSION 2
Minor title and text adjustment.
CVE-2015-8104 has been assigned for the problem with #DB.
(The #AC issue remains CVE-2015-5307.)
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.
Architecturally, at least some of these cases should also be
resolvable by an arriving NMI or external interrupt, but empirically
this has been determined to not be the case.
The cases affecting Xen are:
#AC (Alignment Check Exception, CVE-2015-5307): When a 32-bit guest
sets up the IDT entry corresponding to this exception to reference a
ring-3 handler, and when ring 3 code triggers the exception while
running with an unaligned stack pointer, delivering the exception will
re-encounter #AC, ending in an infinite loop.
#DB (Debug Exception, CVE-2015-8104): When a guest sets up a hardware
breakpoint covering a data structure involved in delivering #DB, upon
completion of the delivery of the first exception another #DB will
need to be delivered. The effects slightly differ depending on further
- - - 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
- - - 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 IST for the IDT entry
corresponding to #DB would enter an infinite loop, as the stack
pointer wouldn't change between #DB instances.
A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant, perhaps
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.
It is possible that a guest kernel might expose the #AC vulnerability
to malicious unprivileged guest users (by permitting #AC to be handled
in guest user mode). However, we believe that almost all ordinary
operating system kernels do not permit this; we are not aware of any
exceptions. (A guest kernel which exposed the #AC vulnerability to
guest userspace would be vulnerable when running on baremetal, without
The vulnerability is exposed to any x86 HVM guest.
ARM is not vulnerable. x86 PV VMs are not vulnerable.
All versions of Xen are affected.
x86 CPUs from all manufacturers are affected.
Running only PV guests will avoid this issue.
Running only kernels which avoid exposing the #AC problem to userspace
(as discussed in Impact) will prevent untrusted guest users from
exploiting this issue.
With such good kernels, the vulnerability can be avoided altogether if
the guest kernel is controlled by the host rather than guest
administrator, provided that further steps are taken to prevent the
guest administrator from loading code into the kernel (e.g. by
disabling loadable modules etc) or from using other mechanisms which
allow them to run code at kernel privilege. In Xen HVM, controlling
the guest's kernel would involve locking down the bootloader.
These issues were discovered by Ben Serebrin from Google and
Jan Beulich from SUSE.
To correctly support the intended uses of the relevant CPU features
would require architectural changes to the CPU specification, design
and implementation. This is not practical as a security response.
Applying the appropriate attached patch works around the issue in
xsa156.patch xen-unstable, Xen 4.6.x
xsa156-4.5.patch Xen 4.5.x
xsa156-4.4.patch Xen 4.4.x
xsa156-4.3.patch Xen 4.3.x
$ sha256sum xsa156*.patch
NOTE REGARDING EMBARGO DURATION
We have released this advisory as soon as possible after we obtained
firm confirmation of the embargo end date from the discoverer.
DEPLOYMENT DURING EMBARGO
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
- -----END PGP SIGNATURE-----
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to firstname.lastname@example.org
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: email@example.com
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----