grant table operations mishandle reference counts

ISSUE DESCRIPTION

We have discovered a number of bugs in the code mapping and unmapping grant references.

• 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. (CVE-2017-10920.)
• 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. (CVE-2017-10921.)
• 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. (CVE-2017-10922.)

IMPACT

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

VULNERABLE SYSTEMS

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.