HVMOP_set_mem_type allows invalid P2M entries to be created

ISSUE DESCRIPTION

The implementation in Xen of the HVMOP_set_mem_type HVM control operations attempts to exclude transitioning a page from an inappropriate memory type. However, only an inadequate subset of memory types is excluded.
There are certain other types that don’t correspond to a particular valid page, whose page table translation can be inappropriately changed (by HVMOP_set_mem_type) from not-present (due to the lack of valid memory page) to present. If this occurs, an invalid translation will be established.

IMPACT

In a configuration where device models run with limited privilege (for example, stubdom device models), a guest attacker who successfully finds and exploits an unfixed security flaw in qemu-dm could leverage the other flaw into a Denial of Service affecting the whole host.
In the more general case, in more abstract terms: a malicious administrator of a domain privileged with regard to an HVM guest can cause Xen to crash leading to a Denial of Service.
Arbitrary code execution, and therefore privilege escalation, cannot be entirely excluded: On a system with a RAM page present immediately below the 52-bit address boundary, this would be possible. However, we are not aware of any systems with such a memory layout.

VULNERABLE SYSTEMS

All Xen versions from 4.1 onwards are vulnerable.
The vulnerability is only exposed to service domains for HVM guests which have privilege over the guest. In a usual configuration that means only device model emulators (qemu-dm).
In the case of HVM guests whose device model is running in an unrestricted dom0 process, qemu-dm already has the ability to cause problems for the whole system. So in that case the vulnerability is not applicable.
The situation is more subtle for an HVM guest with a stub qemu-dm. That is, where the device model runs in a separate domain (in the case of xl, as requested by “device_model_stubdomain_override=1” in the xl domain configuration file). The same applies with a qemu-dm in a dom0 process subjected to some kind kernel-based process privilege limitation (eg the chroot technique as found in some versions of XCP/XenServer).
In those latter situations this issue means that the extra isolation does not provide as good a defence (against denial of service) as intended. That is the essence of this vulnerability.
However, the security is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.
Finally, in a radically disaggregated system: where the HVM service domain software (probably, the device model domain image) is not always supplied by the host administrator, a malicious service domain administrator can exercise this vulnerability.