CVE-2014-3124
http://xenbits.xen.org/xsa/advisory-92.html
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)
http://xenbits.xen.org/xsa/xsa92.patch
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;
}
else
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.
DoS