Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1323955 - (CVE-2016-3960, xsa173) CVE-2016-3960 xsa173 xen: x86 shadow pagetables: address width overflow (XSA-173)
CVE-2016-3960 xsa173 xen: x86 shadow pagetables: address width overflow (XSA-...
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20160418,repor...
: Security
Depends On: 1328118
Blocks: 1323957
  Show dependency treegraph
 
Reported: 2016-04-05 03:42 EDT by Adam Mariš
Modified: 2018-02-26 07:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-26 07:11:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xen 4.3.x (8.97 KB, patch)
2016-04-05 03:49 EDT, Adam Mariš
no flags Details | Diff
Xen 4.4.x (8.97 KB, patch)
2016-04-05 03:49 EDT, Adam Mariš
no flags Details | Diff
Xen 4.5.x (8.90 KB, patch)
2016-04-05 03:50 EDT, Adam Mariš
no flags Details | Diff
Xen 4.6.x (8.89 KB, patch)
2016-04-05 03:50 EDT, Adam Mariš
no flags Details | Diff
xen-unstable (8.77 KB, patch)
2016-04-05 03:50 EDT, Adam Mariš
no flags Details | Diff

  None (edit)
Description Adam Mariš 2016-04-05 03:42:20 EDT
ISSUE DESCRIPTION
=================

In the x86 shadow pagetable code, the guest frame number of a
superpage mapping is stored in a 32-bit field.  If a shadowed guest
can cause a superpage mapping of a guest-physical address at or above
2^44 to be shadowed, the top bits of the address will be lost, causing
an assertion failure or NULL dereference later on, in code that
removes the shadow.


IMPACT
======

A HVM guest using shadow pagetables can cause the host to crash.

A PV guest using shadow pagetables (i.e. being migrated) with PV
superpages enabled (which is not the default) can crash the host, or
corrupt hypervisor memory, and so a privilege escalation cannot be
ruled out.


VULNERABLE SYSTEMS
==================

Xen versions from 3.4 onwards are affected.

Only x86 variants of Xen are susceptible.  ARM variants are not
affected.

HVM guests using shadow mode paging can expose this vulnerability.  HVM
guests using Hardware Assisted Paging (HAP) are unaffected.

Systems running PV guests with PV superpages enabled are vulnerable if
those guests undergo live migration.  PV superpages are disabled by
default, so systems are not vulnerable in this way unless
"allowsuperpage" is on the Xen command line.

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.


MITIGATION
==========

Running only PV guests will avoid this vulnerability, unless PV
superpage support is enabled (see above).

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


External References:

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

Acknowledgements:

Name: the Xen project
Comment 1 Adam Mariš 2016-04-05 03:49 EDT
Created attachment 1143684 [details]
Xen 4.3.x
Comment 2 Adam Mariš 2016-04-05 03:49 EDT
Created attachment 1143685 [details]
Xen 4.4.x
Comment 3 Adam Mariš 2016-04-05 03:50 EDT
Created attachment 1143686 [details]
Xen 4.5.x
Comment 4 Adam Mariš 2016-04-05 03:50 EDT
Created attachment 1143688 [details]
Xen 4.6.x
Comment 5 Adam Mariš 2016-04-05 03:50 EDT
Created attachment 1143689 [details]
xen-unstable
Comment 6 Andrej Nemec 2016-04-18 09:52:49 EDT
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1328118]
Comment 7 Andrej Nemec 2016-04-18 09:53:04 EDT
Public via:

http://seclists.org/oss-sec/2016/q2/92
Comment 8 Fedora Update System 2016-04-29 20:25:00 EDT
xen-4.5.3-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2016-04-30 20:21:57 EDT
xen-4.5.3-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2016-05-07 08:04:16 EDT
xen-4.6.1-6.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

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