[Oraclevm-errata] OVMSA-2017-0177 Important: Oracle VM 3.3 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Wed Dec 13 17:48:46 PST 2017
Oracle VM Security Advisory OVMSA-2017-0177
The following updated rpms for Oracle VM 3.3 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.3.0-55.el6.186.63.x86_64.rpm
xen-tools-4.3.0-55.el6.186.63.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.186.63.src.rpm
Description of changes:
[4.3.0-55.el6.186.63]
- Due to the history performance reason, we decide to disable PoD feature
in old OVM product.XSA-246,XSA-247 [bug 27121016]
{CVE-2017-17044,CVE-2017-17045}
[4.3.0-55.el6.186.62]
- From 2a99aa99fc84a45f505f84802af56b006d14c52e Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Fri, 19 Aug 2016 15:08:10 +0100
Subject: [PATCH] xen/physmap: Do not permit a guest to populate PoD
pages for itself
PoD is supposed to be entirely transparent to guest, but this
interface has
been left exposed for a long time.
The use of PoD requires careful co-ordination by the toolstack with the
XENMEM_{get,set}_pod_target hypercalls, and xenstore ballooning
target. The
best a guest can do without toolstack cooperation crash.
Furthermore, there are combinations of features (e.g. c/s c63868ff
"libxl:
disallow PCI device assignment for HVM guest when PoD is enabled")
which a
toolstack might wish to explicitly prohibit (in this case, because
the two
simply don't function in combination). In such cases, the guest
mustn't be
able to subvert the configuration chosen by the toolstack.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/common/memory.c
Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 27121016]
[4.3.0-55.el6.186.61]
- x86/shadow: correct SH_LINEAR mapping detection in sh_guess_wrmap()
The fix for XSA-243 / CVE-2017-15592 (c/s bf2b4eadcf379) introduced a
change
in behaviour for sh_guest_wrmap(), where it had to cope with no
shadow linear
mapping being present.
As the name suggests, guest_vtable is a mapping of the guests
pagetable, not
Xen's pagetable, meaning that it isn't the pagetable we need to check
for the
shadow linear slot in.
The practical upshot is that a shadow HVM vcpu which switches into
4-level
paging mode, with an L4 pagetable that contains a mapping which
aliases Xen's
SH_LINEAR_PT_VIRT_START will fool the safety check for whether a
SHADOW_LINEAR
mapping is present. As the check passes (when it should have
failed), Xen
subsequently falls over the missing mapping with a pagefault such as:
(XEN) Pagetable walk from ffff8140a0503880:
(XEN) L4[0x102] = 000000046c218063 ffffffffffffffff
(XEN) L3[0x102] = 000000046c218063 ffffffffffffffff
(XEN) L2[0x102] = 000000046c218063 ffffffffffffffff
(XEN) L1[0x103] = 0000000000000000 ffffffffffffffff
This is part of XSA-243.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Tim Deegan <tim at xen.org>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896489] {CVE-2017-15592}
More information about the Oraclevm-errata
mailing list