Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 571556 (CVE-2016-1571)

Summary: <app-emulation/xen-{4.5.2-r4, 4.6.0-r8} <app-emulation/xen-tools-{4.5.2-r4, 4.6.0-r7}: VMX intercept issue with INVLPG on non-canonical address (XSA-168) (CVE-2016-1571)
Product: Gentoo Security Reporter: Kristian Fiskerstrand (RETIRED) <k_f>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: idella4
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also:
Whiteboard: B3 [glsa cve]
Package list:
Runtime testing required: ---
Bug Depends on: 574012    
Bug Blocks:    

Description Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-01-11 15:14:32 UTC
Xen Security Advisory XSA-168

       VMX: intercept issue with INVLPG on non-canonical address

              *** EMBARGOED UNTIL 2016-01-20 12:00 UTC ***


While INVLPG does not cause a General Protection Fault when used on a
non-canonical address, INVVPID in its "individual address" variant,
which is used to back the intercepted INVLPG in certain cases, fails in
such cases. Failure of INVVPID results in a hypervisor bug check.


A malicious guest can crash the host, leading to a Denial of Service.


Xen versions from 3.3 onwards are affected.

Only systems using Intel or Cyrix CPUs are affected. ARM and AMD
systems are unaffected.

Only HVM guests using shadow mode paging can expose this
vulnerability.  PV guests, and HVM guests using Hardware Assisted
Paging (also known as EPT on affected hardware), are unaffected.

Note that while unsupported, guests with enabled nested virtualization
are vulnerable even when using EPT.


To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'.  This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:

  (XEN) General information for domain 2:
  (XEN)     refcnt=1 dying=2 pause_count=2
  (XEN)     nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=262400
  (XEN)     handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=00000000
  (XEN)     paging assistance: hap refcounts translate external
The presence of `hap' here indicates that the host is not
vulnerable to this domain.  For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.

Note that `General information' will also be printed for PV domains.
For most PV domains there will be no `paging assistance' reported.
But PV guests currently being migrated will report
  (XEN)     paging assistance: shadow log_dirty

Overall: a domain can exploit the vulnerability if this debug output
contains a `paging assistance' line which reports `translate' and
which does not report `hap'.


Running only PV guests will avoid this vulnerability.

Running HVM guests on only AMD hardware will also avoid this

Running HVM guests with Hardware Assisted Paging (HAP) enabled will
also avoid this vulnerability.  This is the default mode on hardware
supporting HAP, but can be overridden by hypervisor command line
option and guest configuration setting.  Such overrides ("hap=0" in
either case, with variants like "no-hap" being possible in the
hypervisor command line case) would need to be removed to avoid this


Applying the attached patch resolves this issue.

xsa168.patch      xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x

$ sha256sum xsa168*
c95198a66485d6e538d113ce2b84630d77c15f597113c38fadd6bf1e24e4c8ec  xsa168.patch


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 Ian Delaney (RETIRED) gentoo-dev 2016-01-17 08:54:53 UTC
Well this is unexpected.

 * Failed Patch: xsa167.patch !
 *  ( /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.6.0-r7/work/xen-sec/xsa167.patch )

with the usual

 can't find file to patch at input line 15
Perhaps you used the wrong -p or --strip option?
in xen-tools-4.6.0-r7/temp/xsa167.patch.out

Just to make things more confusing.

 * Applying xsa168.patch ...                                                                                                                                    [ ok ]
 * Applying xsa169.patch ...

 * Failed Patch: xsa169.patch !
 *  ( /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.6.0-r7/work/xen-sec/xsa169.patch )

Removing xsa167.patch from the list allows xsa168.patch to apply, effectively, which then, it appears, contaminates xsa169.patch which was applying fine priot to addition of xsa167.patch & xsa168.patch
Comment 2 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-01-18 14:07:41 UTC
(In reply to Ian Delaney from comment #1)
> Well this is unexpected.
>  * Failed Patch: xsa167.patch !
>  *  (
> /mnt/gen2/TmpDir/portage/app-emulation/xen-tools-4.6.0-r7/work/xen-sec/
> xsa167.patch )

As discussed on IRC this is due to bug 571552 comment 1
Comment 3 Ian Delaney (RETIRED) gentoo-dev 2016-01-19 05:13:54 UTC

/app-emulation/xen $ ebuild xen-4.5.2-r4.ebuild clean prepare

 * Applying xsa165-4.5.patch            [ ok ]
 * Applying xsa166-4.5.patch            [ ok ]
 * Applying xsa167-4.6.patch            [ ok ]
 * Applying xsa168.patch                [ ok ]

app-emulation/xen $ ebuild xen-4.6.0-r8.ebuild clean prepare

 * Applying xsa165-4.6.patch            [ ok ]
 * Applying xsa166.patch                [ ok ]
 * Applying xsa167-4.6.patch            [ ok ]
 * Applying xsa168.patch                [ ok ]
 * Applying xsa169.patch                [ ok ]

ditto xen-tools.

build and install

The first email indicated the patch required was xsa167.patch. Cost me hours. The one that actually works was always there but never used it until exhausting all sane methods of getting the wrong one to work.

Please anyone don't ever do that again.
Comment 4 Kristian Fiskerstrand (RETIRED) gentoo-dev 2016-01-20 12:15:38 UTC
Public release
Comment 5 Ian Delaney (RETIRED) gentoo-dev 2016-01-21 14:33:51 UTC
commit 355e4fcbd3f83ef4b3d435e843503033d1a8c3b8
Author: Ian Delaney <>
Date:   Thu Jan 21 22:07:07 2016 +0800

    app-emulation/xen: revbumps to vns. 4.5.2-r4 4.6.0-r8
    wrt gentoo security bug. patches added; xsa 167-4.6, xsa168
    Purging of old versions to await stabilisation of revbumped vns.
    Gentoo bug: #571556, #571552

commit dd9ecb826db3250e60c35d188804cb16cf0a6dde
Author: Ian Delaney <>
Date:   Thu Jan 21 22:03:25 2016 +0800

    app-emulation/xen-tools: revbumps to vns. 4.5.2-r4 4.6.0-r7
    wrt gentoo security bug. patches added; xsa 167-4.6, xsa168
    Purging of old versions to await stabilisation of revbumped vns.
    Gentoo bug: #571556, #571552
Comment 6 Agostino Sarubbo gentoo-dev 2016-01-21 15:31:35 UTC
Please clearly state WHICH packages need to be stabilized and which versions.
Comment 7 Ian Delaney (RETIRED) gentoo-dev 2016-01-30 12:13:19 UTC
All addressed and managed already in 571552
Comment 8 Aaron Bauman (RETIRED) gentoo-dev 2016-03-12 13:24:40 UTC
Added to existing GLSA.
Comment 9 Yury German Gentoo Infrastructure gentoo-dev 2016-04-05 06:56:06 UTC
Arches and Maintainer(s), Thank you for your work.
Comment 10 GLSAMaker/CVETool Bot gentoo-dev 2016-04-05 07:02:14 UTC
This issue was resolved and addressed in
 GLSA 201604-03 at
by GLSA coordinator Yury German (BlueKnight).