Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 564932 (CVE-2015-5307) - <app-emulation/xen-{4.5.2-r1,4.6.0-r2}: x86: CPU lockup during fault delivery (XSA-156) (CVE-2015-{5307,8104})
Summary: <app-emulation/xen-{4.5.2-r1,4.6.0-r2}: x86: CPU lockup during fault delivery...
Alias: CVE-2015-5307
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa]
Depends on:
Reported: 2015-11-05 11:21 UTC by Kristian Fiskerstrand (RETIRED)
Modified: 2016-04-05 07:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-11-05 11:21:10 UTC
Xen Security Advisory CVE-2015-5307 / XSA-156

                x86: CPU lockup during fault delivery

              *** EMBARGOED UNTIL 2015-11-10 00:01 UTC ***


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): 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): 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 guest

- 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.


A malicious HVM guest administrator can cause a denial of service.
Specifically, prevent use of a physical CPU for a significant, perhaps
indefinite period.

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
Xen involved.)


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.


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
a7f52c56d2f6a89c337a0a6e90c5783bdb07097d806b073043df12a5d43effed  xsa156-4.3.patch
33e8cf12e680f3db7254a177eccf1d1e95c588cba23b858886f1baf26f3eca89  xsa156-4.4.patch
050a10835802e7728f1a3dfe90659ea9938c8becf43264fe5bedfed46777236b  xsa156-4.5.patch
a456ce1f63c92c36772915fa5990403f119cb34e3a336ee08d54230502d70905  xsa156.patch


The #AC issue is CVE-2015-5307.

We believe that the #DB issue will be assigned a different CVE but we
have no confirmation of this at this time.


We have released this advisory as soon as possible after we obtained
firm confirmation of the embargo end date from the discoverer.


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:
Comment 1 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-11-10 08:47:42 UTC
The issue is now public
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2015-11-10 10:16:30 UTC
commit 3c606b8d93fcaff04c463764bb5bab96780654ea
Author: Ian Delaney <>
Date:   Tue Nov 10 18:05:41 2015 +0800

    app-emulation/xen: revbumps; add xsa-156 patches in 4.5 4.5.2-r1, 4.6.0-r2
    Required by gentoo security bug. These are embargoed patches now free
    for public release.
    Gentoo bug: #564932

The addition might need re-doing since it doesn't fit dlan's form but it's trivia. Each new addition requires making of a new .conf file which am not familiar with.

These work
Comment 3 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-11-10 11:18:12 UTC
Arches, please stabilize
Stable targets: amd64 x86
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2015-11-10 11:35:24 UTC
actually x86 was dropped in xen some time ago:

	KEYWORDS="amd64 ~arm ~arm64 -x86"

leaving amd64.  However I see no reason why arm and arm64 should not be made stable but that should be kept for the next stabilising of 4.6.n
Comment 5 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-11-10 11:38:20 UTC
(In reply to Ian Delaney from comment #4)
> actually x86 was dropped in xen some time ago:
> 	KEYWORDS="amd64 ~arm ~arm64 -x86"
> leaving amd64.  However I see no reason why arm and arm64 should not be made
> stable but that should be kept for the next stabilising of 4.6.n

x86 is still stable for 4.2 series, has a due diligence been performed to establish that it is not affected by the security vulnerability, and if so a patch backported?
Comment 6 Agostino Sarubbo gentoo-dev 2015-11-11 08:28:12 UTC
@maintainer, since the xsa says:

> All versions of Xen are affected.

Please clarify if you want to drop 4.2.x or we need to wait the fixed version.
Comment 7 Agostino Sarubbo gentoo-dev 2015-11-11 08:55:06 UTC
amd64 stable
Comment 8 Yixun Lan archtester gentoo-dev 2015-11-16 05:58:36 UTC
(In reply to Agostino Sarubbo from comment #6)
> Please clarify if you want to drop 4.2.x or we need to wait the fixed
> version.

we'll drop 4.2.x, do not waste the effort to stable it
Comment 9 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-11-16 12:16:12 UTC
(In reply to Yixun Lan from comment #8)
> (In reply to Agostino Sarubbo from comment #6)
> > Please clarify if you want to drop 4.2.x or we need to wait the fixed
> > version.
> we'll drop 4.2.x, do not waste the effort to stable it

It should likely be p.masked in that case
Comment 10 Agostino Sarubbo gentoo-dev 2015-11-18 08:30:24 UTC
(In reply to Yixun Lan from comment #8)
> we'll drop 4.2.x, do not waste the effort to stable it

ok, then x86 has nothing to do here.

Please cleanup.
Comment 11 Ian Delaney (RETIRED) gentoo-dev 2015-12-03 12:34:07 UTC
commit 8f7e07bb5fc8f742d97e22fa659f044ebd5cc570
Author: Ian Delaney <>
Date:   Sun Nov 29 15:53:09 2015 +0800

    app-emulation/xen: clean old vns.: 4.5.x, 4.6.0-r1
Comment 12 Yury German Gentoo Infrastructure gentoo-dev 2015-12-08 00:16:41 UTC
Arches and Maintainer(s), Thank you for your work.

Added to an existing GLSA Request.
Comment 13 GLSAMaker/CVETool Bot gentoo-dev 2016-04-05 07:01:23 UTC
This issue was resolved and addressed in
 GLSA 201604-03 at
by GLSA coordinator Yury German (BlueKnight).