HVMOP_set_mem_type allows invalid P2M entries to be created

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.

lack of check (inadequate check)



x86/HVM: restrict HVMOPsetmem_type

Permitting arbitrary type changes here has the potential of creating present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid MFN (INVALID_MFN truncated to the respective hardware structure field’s width).

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4541,12 +4541,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 rc = -EINVAL;
                 goto param_fail4;
-            if ( p2m_is_grant(t) )
+            if ( !p2m_is_ram(t) &&
+                 (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
                 put_gfn(d, pfn);
-                gdprintk(XENLOG_WARNING,
-                         "type for pfn %#lx changed to grant while "
-                         "we were working?\n", pfn);
                 goto param_fail4;


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.