[Oraclevm-errata] OVMSA-2016-0165 Important: Oracle VM 3.3 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Tue Nov 22 19:33:27 PST 2016
Oracle VM Security Advisory OVMSA-2016-0165
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.119.60.x86_64.rpm
xen-tools-4.3.0-55.el6.119.60.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.119.60.src.rpm
Description of changes:
[4.3.0-55.el6.119.60]
- x86/hvm: Fix the handling of non-present segments
In 32bit, the data segments may be NULL to indicate that the segment is
ineligible for use. In both 32bit and 64bit, the LDT selector may be
NULL to
indicate that the entire LDT is ineligible for use. However, nothing
in Xen
actually checks for this condition when performing other segmentation
checks. (Note however that limit and writeability checks are correctly
performed).
Neither Intel nor AMD specify the exact behaviour of loading a NULL
segment.
Experimentally, AMD zeroes all attributes but leaves the base and limit
unmodified. Intel zeroes the base, sets the limit to 0xfffffff and
resets the
attributes to just .G and .D/B.
The use of the segment information in the VMCB/VMCS is equivalent to
a native
pipeline interacting with the segment cache. The present bit can
therefore
have a subtly different meaning, and it is now cooked to uniformly
indicate
whether the segment is usable or not.
GDTR and IDTR don't have access rights like the other segments, but for
consistency, they are treated as being present so no special casing
is needed
elsewhere in the segmentation logic.
AMD hardware does not consider the present bit for %cs and %tr, and will
function as if they were present. They are therefore unconditionally
set to
present when reading information from the VMCB, to maintain the new
meaning of
usability.
Intel hardware has a separate unusable bit in the VMCS segment
attributes.
This bit is inverted and stored in the present field, so the hvm code
can work
with architecturally-common state.
This is XSA-191.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: boris.ostrovsky at oracle.com [bug 25087529] {CVE-2016-9386}
[4.3.0-55.el6.119.59]
- pygrub: Properly quote results, when returning them to the caller:
* When the caller wants sexpr output, use `repr()'
This is what Xend expects.
The returned S-expressions are now escaped and quoted by Python,
generally using '...'. Previously kernel and ramdisk were unquoted
and args was quoted with "..." but without proper escaping. This
change may break toolstacks which do not properly dequote the
returned S-expressions.
* When the caller wants "simple" output, crash if the delimiter is
contained in the returned value.
With --output-format=simple it does not seem like this could ever
happen, because the bootloader config parsers all take line-based
input from the various bootloader config files.
With --output-format=simple0, this can happen if the bootloader
config file contains nul bytes.
This is XSA-198.
Signed-off-by: Ian Jackson <Ian.Jackson at eu.citrix.com>
Tested-by: Ian Jackson <Ian.Jackson at eu.citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Zhigang Wang <zhigang.x.wang at oracle.com> [bug 25094290]
{CVE-2016-9379,CVE-2016-9380}
[4.3.0-55.el6.119.58]
- xen: fix ioreq handling
Avoid double fetches and bounds check size to avoid overflowing
internal variables.
This is XSA-197.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
25094205] {CVE-2016-9381}
[4.3.0-55.el6.119.57]
- x86emul: fix huge bit offset handling
We must never chop off the high 32 bits.
This is XSA-195.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>y
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
25088419] {CVE-2016-9383}
- xen: fix ioreq handling
Avoid double fetches and bounds check size to avoid overflowing
internal variables.
This is XSA-197.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Stefano Stabellini <sstabellini at kernel.org>
Reviewed-by: Ian Jackson <ian.jackson at eu.citrix.com>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
25094205] {CVE-2016-9381}
[4.3.0-55.el6.119.56]
- x86/HVM: don't load LDTR with VM86 mode attrs during task switch
Just like TR, LDTR is purely a protected mode facility and hence needs
to be loaded accordingly. Also move its loading to where it
architecurally belongs.
This is XSA-192.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
25087555] {CVE-2016-9382}
[4.3.0-55.el6.119.55]
- vmx: restore debug registers when injecting #DB traps
Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
injection").
To fix this, restore the original code path through hvm_inject_trap(),
but ensure that the struct hvm_trap is populated with all the required
data.
Signed-off-by: Ross Lagerwall <ross.lagerwall at citrix.com>
Reviewed-by: Jan Beulich <jbeulich at suse.com>
Acked-by: Kevin Tian <kevin.tian at intel.com>
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Upstream commit ba22f1f4732acb4d5aebd779122e91753a0e374d
Backported-by: Dongli Zhang <dongli.zhang at oracle.com> [bug 24792671]
{CVE-2015-5307}
[4.3.0-55.el6.119.54]
- mm: Don't scrub memory if another processor on the same node is
already doing it
There is no reason to have two processors from the same node to scrub
memory
at the same time.
Original fix of the scrubbing problem tried to prevent multiple
scrubbers by
starting scrub processing only when noone was waiting for the node's
heap lock. Apparently this was not sufficient: per 20800450 a
customer still
observed extremely long (minutes) periods when the system is essentially
unusable due to the heap being unavalable.
My theory is that there is still a window where the lock is not held
(first half of __scrub_free_pages()) which may allow at least one
other CPU
from the same node to start scrubbing. I haven't been able to verify this
since I can't reproduce the bug (20800450) but the patch below, which
explicitly allows only one CPU per node to perform scrubbing, appears to
make the problem go away.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
This patch is originally for bug24376653.
Conflicts:
xen/common/page_alloc.c
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24376653]
- x86/vmx: Fix injection of #DB traps following XSA-156
Most #DB exceptions are traps rather than faults, meaning that the
instruction
pointer in the exception frame points after the instruction rather
than at it.
However, VMX intercepts all have fault semantics, even when
intercepting a
trap. Re-injecting an intercepted trap as a fault causes an infinite
loop in
the guest, by re-executing the same trapping instruction repeatedly.
This
breaks debugging inside the guest.
Introduce a helper which copies VM_EXIT_INTR_INTO to
VM_ENTRY_INTR_INFO, and
use it to mirror the intercepted interrupt back to the guest.
Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
Acked-by: Kevin Tian <kevin.tian at intel.com>
master commit: 0747bc8b4d85f3fc0ee1e58418418fa0229e8ff8
master date: 2016-01-05 11:28:56 +0000
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Upstream commit a929bee0e65296ee565251316dc53f1c6b79084a
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Elena Ufimtseva <elena.ufimtseva at oracle.com> [bug
24792671] {CVE-2015-5307}
[4.3.0-55.el6.119.53]
- mm/scrub: clear is_scrubbing flag outside ASSERT()
Otherwise we never clear the flag on NDEBUG builds that turn ASSERT into
a nop.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Acked-by: Adnan Misherfi <adnan.misherfi at oracle.com>
This is backport from 3.4 tree from bug21819046
commit: 886760e191c696464ef3590391d77437244d55a2
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [bug 24376653]
[4.3.0-55.el6.119.52]
- x86emul: honor guest CR0.TS and CR0.EM
We must not emulate any instructions accessing respective registers
when either of these flags is set in the guest view of the register, or
else we may do so on data not belonging to the guest's current task.
Being architecturally required behavior, the logic gets place in the
instruction emulator instead of hvmemul_get_fpu(). It should be noted,
though, that hvmemul_get_fpu() being the only current handler for the
get_fpu() callback, we don't have an active problem with CR4: Both
CR4.OSFXSR and CR4.OSXSAVE get handled as necessary by that function.
This is XSA-190.
Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
---
v2: Require the read_cr hook to be set, which then requires a change to
the test code too.
---
The change to xen/arch/x86/hvm/emulate.c isn't strictly needed for
fixing the security issue, but the patch would be rather incomplete
without.
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 24697330]
More information about the Oraclevm-errata
mailing list