[Oraclevm-errata] OVMSA-2016-0166 Important: Oracle VM 3.2 xen security update
Errata Announcements for Oracle VM
oraclevm-errata at oss.oracle.com
Tue Nov 22 19:33:45 PST 2016
Oracle VM Security Advisory OVMSA-2016-0166
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.44.x86_64.rpm
xen-devel-4.1.3-25.el5.223.44.x86_64.rpm
xen-tools-4.1.3-25.el5.223.44.x86_64.rpm
SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.223.44.src.rpm
Description of changes:
[4.1.3-25.el5.223.44]
- 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 25087532] {CVE-2016-9386}
[4.1.3-25.el5.223.43]
- 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 25094313]
{CVE-2016-9379,CVE-2016-9380}
[4.1.3-25.el5.223.42]
- 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
25094225] {CVE-2016-9381}
[4.1.3-25.el5.223.41]
- 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>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug
25088667] {CVE-2016-9383}
[4.1.3-25.el5.223.40]
- 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
25087565] {CVE-2016-9382}
[4.1.3-25.el5.223.39]
- xen: correctly handle debug trap in VMEXIT handler - XSA-156
This patch fixes the VM crash when guests tiggers debug exception
by correctly handling VMEXIT by trapping into debugger if its activated.
This patch also a part of a backport of XSA-156 for xen-4.1.x.
There is no commit in upstream tree, but the patch was posted
in the discussion:
https://lists.xen.org/archives/html/xen-devel/2015-11/msg02602.html
and proposed by Jan Beulich.
Signed-of-by: Elena Ufimtseva <elena.ufimtseva at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Tested-by: Elena Ufimtseva <elena.ufimtseva at oracle.com>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com> [bug 25034406]
{CVE-2015-5307}
[4.1.3-25.el5.223.38]
- 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>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Reviewed-by: Bob Liu <bob.liu at oracle.com>
Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
Backported-by: Dongli Zhang <dongli.zhang at oracle.com> [bug 20800450]
[4.1.3-25.el5.223.37]
- 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.
---
Conflicts:
tools/tests/x86_emulator/test_x86_emulator.c
xen/arch/x86/hvm/emulate.c
Backported-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Reviewed-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 24697412]
More information about the Oraclevm-errata
mailing list