Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1296544 (CVE-2016-1571, xsa168)

Summary: CVE-2016-1571 xen: Intercept issue with INVLPG on non-canonical address causing host to crash
Product: [Other] Security Response Reporter: Adam Mariš <amaris>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: ailan, drjones, imammedo, knoel, mrezanin, pbonzini, rkrcmar, security-response-team, vkuznets, xen-maint
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-26 12:02:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1300342    
Bug Blocks:    
Attachments:
Description Flags
patch for xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x none

Description Adam Mariš 2016-01-07 13:40:05 UTC
ISSUE DESCRIPTION
=================

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.

IMPACT
======

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

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

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.

CHECKING FOR VULNERABLE CONFIGURATION
=====================================

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

MITIGATION
==========

Running only PV guests will avoid this vulnerability. Running HVM guests on only AMD hardware will also avoid this vulnerability. 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.

Comment 1 Adam Mariš 2016-01-07 13:40:56 UTC
Created attachment 1112465 [details]
patch for xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x

Comment 2 Adam Mariš 2016-01-07 15:09:24 UTC
Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue.

Comment 3 Andrej Nemec 2016-01-20 14:11:13 UTC
Created xen tracking bugs for this issue:

Affects: fedora-all [bug 1300342]

Comment 4 Andrej Nemec 2016-01-20 14:12:49 UTC
Public via:

http://seclists.org/oss-sec/2016/q1/156

Comment 5 Fedora Update System 2016-01-28 18:24:42 UTC
xen-4.5.2-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2016-02-01 06:29:44 UTC
xen-4.5.2-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.