OVMSA-2016-0007 - xen security update
| Type: | SECURITY |
| Severity: | IMPORTANT |
| Release Date: | 2016-01-25 |
Description
[4.3.0-55.el6.47.70]
- x86/VMX: prevent INVVPID failure due to non-canonical guest address
While INVLPG (and on SVM INVLPGA) don't fault on non-canonical
addresses, INVVPID fails (in the 'individual address' case) when passed
such an address.
Since such intercepted INVLPG are effectively no-ops anyway, don't fix
this in vmx_invlpg_intercept(), but instead have paging_invlpg() never
return true in such a case.
This is XSA-168.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Ian Campbell
Acked-by: Chuck Anderson [bug 22584919] {CVE-2016-1571}
[4.3.0-55.el6.47.69]
- x86/mm: PV superpage handling lacks sanity checks
MMUEXT_{,UN}MARK_SUPER fail to check the input MFN for validity before
dereferencing pointers into the superpage frame table.
get_superpage() has a similar issue.
This is XSA-167.
Reported-by: Qinghao Tang
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
Acked-by: Chuck Anderson [bug 22584899] {CVE-2016-1570}
[4.3.0-55.el6.47.68]
- x86/HVM: avoid reading ioreq state more than once
Otherwise, especially when the compiler chooses to translate the
switch() to a jump table, unpredictable behavior (and in the jump table
case arbitrary code execution) can result.
This is XSA-166.
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
Acked-by: Chuck Anderson [bug 22551303]
[4.3.0-55.el6.47.67]
- x86: don't leak ST(n)/XMMn values to domains first using them
FNINIT doesn't alter these registers, and hence using it is
insufficient to initialize a guest's initial state.
This is XSA-165.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Chuck Anderson [bug 22551295] {CVE-2015-8555}
[4.3.0-55.el6.47.66]
- MSI-X: avoid array overrun upon MSI-X table writes
pt_msix_init() allocates msix->msix_entry[] to just cover
msix->total_entries entries. While pci_msix_readl() resorts to reading
physical memory for out of bounds reads, pci_msix_writel() so far
simply accessed/corrupted unrelated memory.
pt_iomem_map()'s call to cpu_register_physical_memory() registers a
page granular region, which is necessary as the Pending Bit Array may
share space with the MSI-X table (but nothing else is allowed to). This
also explains why pci_msix_readl() actually honors out of bounds reads,
but pci_msi_writel() doesn't need to.
This is XSA-164.
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
Acked-by: Chuck Anderson [bug 22551252] {CVE-2015-8554}
[4.3.0-55.el6.47.65]
- From 43a10fecd6f4a9d8adf9f5d85e3d5e7187e2d54a Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Wed, 18 Nov 2015 15:34:54 +0000
Subject: [PATCH] libxl: Fix bootloader-related virtual memory leak on pv
build failure
The bootloader may call libxl__file_reference_map(), which mmap's the
pv_kernel and pv_ramdisk into process memory. This was only unmapped,
however, on the success path of libxl__build_pv(). If there were a
failure anywhere between libxl_bootloader.c:parse_bootloader_result()
and the end of libxl__build_pv(), the calls to
libxl__file_reference_unmap() would be skipped, leaking the mapped
virtual memory.
Ideally this would be fixed by adding the unmap calls to the
destruction path for libxl__domain_build_state. Unfortunately the
lifetime of the libxl__domain_build_state is opaque, and it doesn't
have a proper destruction path. But, the only thing in it that isn't
from the gc are these bootloader references, and they are only ever
set for one libxl__domain_build_state, the one which is
libxl__domain_create_state.build_state.
So we can clean up in the exit path from libxl__domain_create_*, which
always comes through domcreate_complete.
Remove the now-redundant unmaps in libxl__build_pv's success path.
This is XSA-160.
Acked-by: Ian Campbell
Based on xen.org's xsa160.patch
Conflicts:
adjust patch context to match OVM 3.3 code base
Acked-by: Chuck Anderson
Reviewed-by: John Haxby
Tested-by: Boris Ostrovsky [bug 22326164] {CVE-2015-8341}
[4.3.0-55.el6.47.64]
- memory: fix XENMEM_exchange error handling
assign_pages() can fail due to the domain getting killed in parallel,
which should not result in a hypervisor crash.
Also delete a redundant put_gfn() - all relevant paths leading to the
'fail' label already do this (and there are also paths where it was
plain wrong). All of the put_gfn()-s got introduced by 51032ca058
('Modify naming of queries into the p2m'), including the otherwise
unneeded initializer for k (with even a kind of misleading comment -
the compiler warning could actually have served as a hint that the use
is wrong).
This is XSA-159.
Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
Acked-by: Chuck Anderson
Reviewed-by: John Haxby
Tested-by: Boris Ostrovsky [bug 22326022] {CVE-2015-8339,CVE-2015-8340}
[4.3.0-55.el6.47.63]
- x86/HVM: always intercept #AC and #DB
Both being benign exceptions, and both being possible to get triggered
by exception delivery, this is required to prevent a guest from locking
up a CPU (resulting from no other VM exits occurring once getting into
such a loop).
The specific scenarios:
1) #AC may be raised during exception delivery if the handler is set to
be a ring-3 one by a 32-bit guest, and the stack is misaligned.
2) #DB may be raised during exception delivery when a breakpoint got
placed on a data structure involved in delivering the exception. This
can result in an endless loop when a 64-bit guest uses a non-zero IST
for the vector 1 IDT entry, but even without use of IST the time it
takes until a contributory fault would get raised (results depending
on the handler) may be quite long.
This is XSA-156.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Tested-by: Andrew Cooper
Acked-by: Chuck Anderson
Reviewed-by: John Haxby [bug 22171747] {CVE-2015-5307,CVE-2015-8104}
Related CVEs
Updated Packages
| Release/Architecture | Filename | MD5sum | Superseded By Advisory |
|
| Oracle VM 3.3 (x86_64) | xen-4.3.0-55.el6.47.70.src.rpm | 3119fc466aa13a1e40dbcf6ab66399a6 | OVMSA-2021-0014 |
| xen-4.3.0-55.el6.47.70.x86_64.rpm | acdc2a1ba8419f9757be61b28192f00b | OVMSA-2021-0014 |
| xen-tools-4.3.0-55.el6.47.70.x86_64.rpm | 5823a5bc364925fb4762908a73b6b5de | OVMSA-2021-0014 |
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
