[Oraclevm-errata] OVMSA-2017-0162 Important: Oracle VM 3.2 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Thu Oct 26 17:05:55 PDT 2017
Oracle VM Security Advisory OVMSA-2017-0162
The following updated rpms for Oracle VM 3.2 have been uploaded to the
Unbreakable Linux Network:
x86_64:
xen-4.1.3-25.el5.223.96.x86_64.rpm
xen-devel-4.1.3-25.el5.223.96.x86_64.rpm
xen-tools-4.1.3-25.el5.223.96.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.223.96.src.rpm
Description of changes:
[4.1.3-25.el5.223.96]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86/cpu: fix IST handling during PCPU bringup
Clear IST references in newly allocated IDTs. Nothing good will come of
having them set before the TSS is suitably constructed (although the
chances
of the CPU surviving such an IST interrupt/exception is extremely slim).
Uniformly set the IST references after the TSS is in place. This
fixes an
issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM
context
will cause IST_NONE to be copied into the new IDT, making that PCPU
vulnerable
to privilege escalation from PV guests until it subsequently
schedules an HVM
guest.
This is XSA-244.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/arch/x86/smpboot.c
Move IST setting in subarch_percpu_traps_init() as no
load_system_tables() here
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896601] {CVE-2017-15594}
[4.1.3-25.el5.223.95]
- From 74fa570daea059d84d8533997f79af6544f1124a Mon Sep 17 00:00:00 2001
From: Andrew Cooper <andrew.cooper3 at citrix.com>
Date: Tue, 11 Dec 2012 17:49:19 +0100
Subject: [PATCH] x86/IST: Create set_ist() helper function
... to save using open-coded bitwise operations, and update all IST
manipulation sites to use the function.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Committed-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/arch/x86/hvm/svm/svm.c
xen/include/asm-x86/processor.h
Prerequisite patch for XSA-244
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896604]
[4.1.3-25.el5.223.94]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86/shadow: Don't create self-linear shadow mappings for
4-level translated guests
When initially creating a monitor table for 4-level translated
guests, don't
install a shadow-linear mapping. This mapping is actually
self-linear, and
trips up the writeable heuristic logic into following Xen's mappings,
not the
guests' shadows it was expecting to follow.
A consequence of this is that sh_guess_wrmap() needs to cope with
there being
no shadow-linear mapping present, which in practice occurs once each
time a
vcpu switches to 4-level paging from a different paging mode.
An appropriate shadow-linear slot will be inserted into the monitor table
either while constructing lower level monitor tables, or by
sh_update_cr3().
While fixing this, clarify the safety of the other mappings. Despite
appearing unsafe, it is correct to create a guest-linear mapping for
translated domains; this is self-linear and doesn't point into the
translated
domain. Drop a dead clause for translate != external guests.
This is part of XSA-243.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Tim Deegan <tim at xen.org>
Conflict:
xen/arch/x86/mm/shadow/multi.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26976552] {CVE-2017-15592}
[4.1.3-25.el5.223.93]
- From: Andrew Cooper <andrew.cooper3 at citrix.com>
Subject: x86: Disable the use of auto-translated PV guests
This is a minimal backport of c/s 92942fd3d469 "x86/mm: drop
guest_{map,get_eff}_l1e() hooks" from Xen 4.7, which stated:
Disallow the unmaintained and presumed broken translated-but-not-external
paging mode combination ...
It turns out that this mode is insecure to run with, as opposed to
just simply
broken.
This is part of XSA-243.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26976552]
[4.1.3-25.el5.223.92]
- From: Jan Beulich <jbeulich at suse.com>
Subject: x86: don't allow page_unlock() to drop the last type reference
Only _put_page_type() does the necessary cleanup, and hence not all
domain pages can be released during guest cleanup (leaving around
zombie domains) if we get this wrong.
This is XSA-242.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896487] {CVE-2017-15593}
[4.1.3-25.el5.223.91]
- From: Jan Beulich <jbeulich at suse.com>
Subject: x86: don't store possibly stale TLB flush time stamp
While the timing window is extremely narrow, it is theoretically
possible for an update to the TLB flush clock and a subsequent flush
IPI to happen between the read and write parts of the update of the
per-page stamp. Exclude this possibility by disabling interrupts
across the update, preventing the IPI to be serviced in the middle.
This is XSA-241.
Suggested-by: George Dunlap <george.dunlap at citrix.com>
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: George Dunlap <george.dunlap at citrix.com>
Conflict:
xen/arch/x86/mm.c
xen/common/page_alloc.c
Add '#include <xen/mm.h>' in xen/arch/x86/machine_kexec.c for
dependency reason
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896481] {CVE-2017-15588}
[4.1.3-25.el5.223.90]
- x86/mm: Disable PV linear pagetables by default
Allowing pagetables to point to other pagetables of the same level
(often called 'linear pagetables') has been included in Xen since its
inception. But it is not used by the most common PV guests (Linux,
NetBSD, minios), and has been the source of a number of subtle
reference-counting bugs.
Add a command-line option to control whether PV linear pagetables are
allowed (disabled by default).
Signed-off-by: George Dunlap <george.dunlap at citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Changes since v2:
- s/_/-/; in command-line option
- Added __read_mostly
Conflict (below file does not exist in OVM3.2):
docs/misc/xen-command-line.markdown
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug
26896441] {CVE-2017-15595}
[4.1.3-25.el5.223.89]
- From: Jan Beulich <jbeulich at suse.com>
Subject: x86/HVM: prefill partially used variable on emulation paths
Certain handlers ignore the access size (vioapic_write() being the
example this was found with), perhaps leading to subsequent reads
seeing data that wasn't actually written by the guest. For
consistency and extra safety also do this on the read path of
hvm_process_io_intercept(), even if this doesn't directly affect what
guests get to see, as we've supposedly already dealt with read handlers
leaving data completely unitialized.
This is XSA-239.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Conflict:
xen/arch/x86/hvm/intercept.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896437] {CVE-2017-15589}
[4.1.3-25.el5.223.88]
- From: Jan Beulich <jbeulich at suse.com>
Subject: x86/MSI: disallow redundant enabling
At the moment, Xen attempts to allow redundant enabling of MSI by
having pci_enable_msi() return 0, and point to the existing MSI
descriptor, when the msi already exists.
Unfortunately, if subsequent errors are encountered, the cleanup
paths assume pci_enable_msi() had done full initialization, and
hence undo everything that was assumed to be done by that
function without also undoing other setup that would normally
occur only after that function was called (in map_domain_pirq()
itself).
Rather than try to make the redundant enabling case work properly, just
forbid it entirely by having pci_enable_msi() return -EEXIST when MSI
is already set up.
This is part of XSA-237.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: George Dunlap <george.dunlap at citrix.com>
Conflict:
xen/arch/x86/msi.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug
26896408] {CVE-2017-15590}
[4.1.3-25.el5.223.87]
- From: Jan Beulich <jbeulich at suse.com>
Subject: x86: don't allow MSI pIRQ mapping on unowned device
MSI setup should be permitted only for existing devices owned by the
respective guest (the operation may still be carried out by the domain
controlling that guest).
This is part of XSA-237.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Conflict:
xen/arch/x86/irq.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 26896406]
More information about the Oraclevm-errata
mailing list