File 535fa503-x86-HVM-restrict-HVMOP_set_mem_type.patch of Package xen

Overview Repositories Revisions Requests Users Attributes Meta

File 535fa503-x86-HVM-restrict-HVMOP_set_mem_type.patch of Package xen (Revision ebad7ca8305e30daec357d388638721b)

Currently displaying revision ebad7ca8305e30daec357d388638721b , Show latest

References: bnc#875668 CVE-2014-3124 XSA-92

# Commit 83bb5eb4d340acebf27b34108fb1dae062146a68
# Date 2014-04-29 15:11:31 +0200
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
x86/HVM: restrict HVMOP_set_mem_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). This would become a problem the latest when something real sat
at the end of the physical address space; I'm suspecting though that
other things might break with such bogus entries.

Along with that drop a bogus (and otherwise becoming stale) log
message.

Afaict the similar operation in p2m_set_mem_access() is safe.

This is CVE-2014-3124 / XSA-92.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4410,12 +4410,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

Places

File 535fa503-x86-HVM-restrict-HVMOP_set_mem_type.patch of Package xen (Revision ebad7ca8305e30daec357d388638721b)

Places