We have discovered a number of bugs in the code mapping and unmapping
* If a grant is mapped with both the GNTMAP_device_map and
GNTMAP_host_map flags, but unmapped only with host_map, the device_map
portion remains but the page reference counts are lowered as though it
had been removed. This bug can be leveraged cause a page's reference
counts and type counts to fall to zero while retaining writeable
mappings to the page.
* Under some specific conditions, if a grant is mapped with both the
GNTMAP_device_map and GNTMAP_host_map flags, the operation may not
grab sufficient type counts. When the grant is then unmapped, the
type count will be erroneously reduced. This bug can be leveraged
cause a page's reference counts and type counts to fall to zero while
retaining writeable mappings to the page.
* When a grant reference is given to an MMIO region (as opposed to a
normal guest page), if the grant is mapped with only the
GNTMAP_device_map flag set, a mapping is created at host_addr anyway.
This does *not* cause reference counts to change, but there will be no
record of this mapping, so it will not be considered when reporting
whether the grant is still in use.
For the worst issue, a PV guest could gain a writeable mapping of its
own pagetable, allowing it to escalate its privileges to that of the
All versions of Xen are vulnerable.
Only x86 systems are vulnerable.
Any system running untrusted PV guests is vulnerable.
Systems with untrusted HVM guests are only vulnerable if those guests
are served by a trusted PV backend which is vulnerable: Namely, one
which calls grant_map() with both the GNTMAP_device_map and
GNTMAP_host_map flags. The security team is not aware of any backends
which are vulnerable.
Running only HVM guests will avoid this vulnerability.
Name: the Xen project
Upstream: Jan Beulich (SUSE)
Created xen tracking bugs for this issue:
Affects: fedora-all [bug 1463247]