[Oraclevm-errata] OVMSA-2016-0007 Important: Oracle VM 3.3 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2016-0007

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.47.70.x86_64.rpm
xen-tools-4.3.0-55.el6.47.70.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.3/SRPMS-updates/xen-4.3.0-55.el6.47.70.src.rpm



Description of changes:

[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 <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [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 <luodalongde at gmail.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [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 <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [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 <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 22551252] 
{CVE-2015-8554}

[4.3.0-55.el6.47.65]
- From 43a10fecd6f4a9d8adf9f5d85e3d5e7187e2d54a Mon Sep 17 00:00:00 2001
   From: Ian Jackson <ian.jackson at eu.citrix.com>
   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 <ian.campbell at citrix.com>
   Based on xen.org's xsa160.patch
   Conflicts:
   adjust patch context to match OVM 3.3 code base
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com>
   Tested-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [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 <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com>
   Tested-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> [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 <jbeulich at suse.com>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 22171747] 
{CVE-2015-5307,CVE-2015-8104}