OVMSA-2016-0165 - xen security update
| Type: | SECURITY |
| Impact: | IMPORTANT |
| Release Date: | 2016-11-22 |
Description
[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 dont 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
Reviewed-by: Jan Beulich
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Backported-by: Dongli Zhang
Reviewed-by: boris.ostrovsky@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
Tested-by: Ian Jackson
Reviewed-by: Andrew Cooper
Backported-by: Dongli Zhang
Reviewed-by: Zhigang Wang [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
Reviewed-by: Stefano Stabellini
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [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
Reviewed-by: Andrew Cooper y
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [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
Reviewed-by: Stefano Stabellini
Reviewed-by: Ian Jackson
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [bug 25094205] {CVE-2016-9381}
[4.3.0-55.el6.119.56]
- x86/HVM: dont 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
Reviewed-by: Andrew Cooper
Tested-by: Andrew Cooper
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [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
Reviewed-by: Jan Beulich
Acked-by: Kevin Tian
Conflicts:
xen/arch/x86/hvm/vmx/vmx.c
Upstream commit ba22f1f4732acb4d5aebd779122e91753a0e374d
Backported-by: Dongli Zhang [bug 24792671] {CVE-2015-5307}
[4.3.0-55.el6.119.54]
- mm: Dont 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 nodes
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 havent been able to verify this
since I cant 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
This patch is originally for bug24376653.
Conflicts:
xen/common/page_alloc.c
Backported-by: Dongli Zhang
Reviewed-by: Boris Ostrovsky [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
Acked-by: Kevin Tian
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
Reviewed-by: Elena Ufimtseva [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
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Adnan Misherfi
This is backport from 3.4 tree from bug21819046
commit: 886760e191c696464ef3590391d77437244d55a2
Backported-by: Dongli Zhang
Reviewed-by: Boris Ostrovsky [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 guests 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 dont 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
Reviewed-by: Andrew Cooper
---
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 isnt strictly needed for
fixing the security issue, but the patch would be rather incomplete
without.
Backported-by: Zhenzhong Duan [bug 24697330]
Related CVEs
Updated Packages
| Release/Architecture | Filename | sha256 | Superseded By Advisory | Channel Label |
|
| Oracle VM 3.3 (x86_64) | xen-4.3.0-55.el6.119.60.src.rpm | 77152137ff5031f0dc96c5bb224314816874775680b0224917fe1c3d14970bca | OVMBA-2024-0012 | ovm3_x86_64_3.3_patch |
| xen-4.3.0-55.el6.119.60.x86_64.rpm | a6df151dcdef3edc212bcf00901a16edd52cbd1a77b57a4ff195de622c17a97c | OVMBA-2024-0012 | ovm3_x86_64_3.3_patch |
| xen-tools-4.3.0-55.el6.119.60.x86_64.rpm | 636737330e3076f3767253bbfcfc992dcfaa995dbae0c08cd1fd911a2e217104 | OVMBA-2024-0012 | ovm3_x86_64_3.3_patch |
This page is generated automatically and has not been checked for errors or omissions. For clarification
or corrections please contact the Oracle Linux ULN team
