OVMSA-2016-0166 - xen security update
| Type: | SECURITY |
| Impact: | IMPORTANT |
| Release Date: | 2016-11-22 |
Description
[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 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 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
Tested-by: Ian Jackson
Reviewed-by: Andrew Cooper
Backported-by: Dongli Zhang
Reviewed-by: Zhigang Wang [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
Reviewed-by: Stefano Stabellini
Reviewed-by: Ian Jackson
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [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
Reviewed-by: Andrew Cooper
Backported-by: Dongli Zhang
Reviewed-by: Konrad Rzeszutek Wilk [bug 25088667] {CVE-2016-9383}
[4.1.3-25.el5.223.40]
- 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 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
Reviewed-by: Boris Ostrovsky
Tested-by: Elena Ufimtseva
Backported-by: Dongli Zhang [bug 25034406] {CVE-2015-5307}
[4.1.3-25.el5.223.38]
- 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
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Bob Liu
Acked-by: Chuck Anderson
Backported-by: Dongli Zhang [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 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.
---
Conflicts:
tools/tests/x86_emulator/test_x86_emulator.c
xen/arch/x86/hvm/emulate.c
Backported-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Reviewed-by: Chuck Anderson [bug 24697412]
Related CVEs
Updated Packages
| Release/Architecture | Filename | sha256 | Superseded By Advisory | Channel Label |
|
| Oracle VM 3.2 (x86_64) | xen-4.1.3-25.el5.223.44.src.rpm | 8647d4194df5fe7380a2c29fc813e2f9756d981004269659b4ba3b32afca1fa8 | OVMBA-2024-0012 | ovm3_3.2.1_x86_64_patch |
| xen-4.1.3-25.el5.223.44.x86_64.rpm | 413bcdff4e4ccab0b089d9b74c141a6e10adfcac22a09e1577a78c32865b662a | OVMBA-2024-0012 | ovm3_3.2.1_x86_64_patch |
| xen-devel-4.1.3-25.el5.223.44.x86_64.rpm | 97226f46be12f735b218418c05392787aa568025780801e4c4a6f92ca8bb65c2 | OVMSA-2019-0048 | ovm3_3.2.1_x86_64_patch |
| xen-tools-4.1.3-25.el5.223.44.x86_64.rpm | 006081e0b203626c3ee3094d2fb3e016442001daa5282e6674c9f025225516e5 | OVMBA-2024-0012 | ovm3_3.2.1_x86_64_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
