ISSUE DESCRIPTION
=================

Grant tables come in two flavors (versions), and domains are permitted
to freely change between them (subject to certain constraints).  For
the guest to use the facility, both the "normal" shared pages
(applicable to v1 and v2) and the "status" pages (applicable to v2
only) need to be mapped by the guest into its address space.

When transitioning from v2 to v1, the status pages become unnecessary
and are therefore freed by Xen.  That means Xen needs to check that
there are no mappings of those pages by the domain.  However, that
check was mistakenly implemented as a bug check, rather than returning
an error to the guest.

IMPACT
======

A malicious or buggy guest may cause a hypervisor crash, resulting in
a Denial of Service (DoS) affecting the entire host.  Privilege
escalation as well as information leaks cannot be ruled out for HVM,
PVH (both x86), and ARM guests.

The impact is more severe for Xen versions 4.0.x, 4.1.0 ... 4.1.3, and
4.2 in that the pages are freed without any checking, thus allowing
their re-use for another domain, or by Xen itself, while there still
are active mappings (see XSA-26).

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

Xen versions 4.0 and newer are vulnerable.

Both x86 and ARM systems are vulnerable.

MITIGATION
==========

Using the "gnttab=max_ver:1" hypervisor command line option, where
available, to disable use of v2 grant tables allows to avoid the
vulnerability.  Use of this option will, however, break any guests which
require to make use of v2 functionality.  The patch introducing this
option was not merged so far, but is available (in its current form) at
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00059.html
("common/gnttab: Introduce command line feature controls").

There is no other known mitigation.

External References:

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