summaryrefslogtreecommitdiff
path: root/kernels/xen/xsa92.patch
diff options
context:
space:
mode:
Diffstat (limited to 'kernels/xen/xsa92.patch')
-rw-r--r--kernels/xen/xsa92.patch36
1 files changed, 36 insertions, 0 deletions
diff --git a/kernels/xen/xsa92.patch b/kernels/xen/xsa92.patch
new file mode 100644
index 000000000..60ef934aa
--- /dev/null
+++ b/kernels/xen/xsa92.patch
@@ -0,0 +1,36 @@
+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 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
+@@ -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