Bug 1458873 (CVE-2017-10915, xsa219) - CVE-2017-10915 xsa219 xen: x86: insufficient reference counts during shadow emulation (XSA-219)
Summary: CVE-2017-10915 xsa219 xen: x86: insufficient reference counts during shadow e...
Alias: CVE-2017-10915, xsa219
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1463247
TreeView+ depends on / blocked
Reported: 2017-06-05 17:43 UTC by Adam Mariš
Modified: 2021-02-17 02:04 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-24 09:21:34 UTC

Attachments (Terms of Use)

Description Adam Mariš 2017-06-05 17:43:06 UTC

When using shadow paging, writes to guest pagetables must be trapped and
emulated, so the shadows can be suitably adjusted as well.

When emulating the write, Xen maps the guests pagetable(s) to make the final
adjustment and leave the guest's view of its state consistent.

However, when mapping the frame, Xen drops the page reference before
performing the write.  This is a race window where the underlying frame can
change ownership.

One possible attack scenario is for the frame to change ownership and to be
inserted into a PV guest's pagetables.  At that point, the emulated write will
be an unaudited modification to the PV pagetables whose value is under guest


A malicious pair of guests may be able to elevate their privilege to that of


All versions of Xen are vulnerable.

Only x86 systems are affected.  ARM systems are not vulnerable.

HVM guests using shadow mode paging can exploit this vulnerability.  HVM guests
using Hardware Assisted Paging (HAP) cannot exploit this vulnerability.

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.

Xen 4.6 and later have the option to compile-out shadow paging support.  (The
default is to compile with shadow paging support).  If Xen is built without
shadow support, it is not vulnerable.

Exploiting this race condition requires coordination between an x86 HVM guest
using shadow paging, and a PV guest.

Running only HVM guests avoids the vulnerability, unless stub device
models are in use (since stub device models are PV domains, each
controlled by the corresponding guest).

Running only PV guests avoids the vulnerability.


Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests.  HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.

(This mitigation is not applicable to PV guests.)

External References:



Name: the Xen project
Upstream: Andrew Cooper (Citrix)

Comment 1 Adam Mariš 2017-06-20 12:35:29 UTC
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1463247]

Note You need to log in before you can comment on or make changes to this bug.