[Oraclevm-errata] OVMSA-2015-0096 Important: Oracle VM 3.2 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2015-0096

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.127.60.x86_64.rpm
xen-devel-4.1.3-25.el5.127.60.x86_64.rpm
xen-tools-4.1.3-25.el5.127.60.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.2/SRPMS-updates/xen-4.1.3-25.el5.127.60.src.rpm



Description of changes:

[4.1.3-25.el5.127.60]
- ide: Clear DRQ after handling all expected accesses
   This is additional hardening against an end_transfer_func that fails to
   clear the DRQ status bit. The bit must be unset as soon as the PIO
   transfer has completed, so it's better to do this in a central place
   instead of duplicating the code in all commands (and forgetting it in
   some).
   Signed-off-by: Kevin Wolf <kwolf at redhat.com>
   This is XSA-138 CVE-2015-5154
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com>
   Tested-by: boris.ostrovsky at oracle.com
   Tested-by: konrad.wilk at oracle.com [bug 21497210] {CVE-2015-5154}

[4.1.3-25.el5.127.59]
- ide: Check array bounds before writing to io_buffer
   If the end_transfer_func of a command is called because enough data has
   been read or written for the current PIO transfer, and it fails to
   correctly call the command completion functions, the DRQ bit in the
   status register and s->end_transfer_func may remain set. This allows the
   guest to access further bytes in s->io_buffer beyond s->data_end, and
   eventually overflowing the io_buffer.
   One case where this currently happens is emulation of the ATAPI command
   START STOP UNIT.
   This patch fixes the problem by adding explicit array bounds checks
   before accessing the buffer instead of relying on end_transfer_func to
   function correctly.
   Cc: qemu-stable at nongnu.org
   Signed-off-by: Kevin Wolf <kwolf at redhat.com>
   This is XSA-138 CVE-2015-5154
   Acked-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com>
   Tested-by: boris.ostrovsky at oracle.com
   Tested-by: konrad.wilk at oracle.com [bug 21497210] {CVE-2015-5154}

[4.1.3-25.el5.127.58]
- tools: libxl: Explicitly disable graphics backends on qemu cmdline
   By default qemu will try to create some sort of backend for the
   emulated VGA device, either SDL or VNC.
   However when the user specifies sdl=0 and vnc=0 in their configuration
   libxl was not explicitly disabling either backend, which could lead to
   one unexpectedly running.
   If either sdl=1 or vnc=1 is configured then both before and after this
   change only the backends which are explicitly enabled are configured,
   i.e. this issue only occurs when all backends are supposed to have
   been disabled.
   This affects qemu-xen and qemu-xen-traditional differently.
   If qemu-xen was compiled with SDL support then this would result in an
   SDL window being opened if $DISPLAY is valid, or a failure to start
   the guest if not. Passing "-display none" to qemu before any further
   -sdl options disables this default behaviour and ensures that SDL is
   only started if the libxl configuration demands it.
   If qemu-xen was compiled without SDL support then qemu would instead
   start a VNC server listening on ::1 (IPv6 localhost) or 127.0.0.1
   (IPv4 localhost) with IPv6 preferred if available. Explicitly pass
   "-vnc none" when vnc is not enabled in the libxl configuration to
   remove this possibility.
   qemu-xen-traditional would never start a vnc backend unless asked.
   However by default it will start an SDL backend, the way to disable
   this is to pass a -vnc option. In other words passing "-vnc none" will
   disable both vnc and sdl by default. sdl can then be reenabled if
   configured by subsequent use of the -sdl option.
   Tested with both qemu-xen and qemu-xen-traditional built with SDL
   support and:
   xl cr # defaults
   xl cr sdl=0 vnc=0
   xl cr sdl=1 vnc=0
   xl cr sdl=0 vnc=1
   xl cr sdl=0 vnc=0 vga="none"
   xl cr sdl=0 vnc=0 nographic=1
   with both valid and invalid $DISPLAY.
   This is XSA-119 / CVE-2015-2152.
   Reported-by: Sander Eikelenboom <linux at eikelenboom.it>
   Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com> [bug 
20968962] {CVE-2015-2152}

[4.1.3-25.el5.127.57]
- x86emul: enforce privilege level restrictions when loading CS
   Privilege level checks were basically missing for the CS case, the
   only check that was done (RPL == DPL for nonconforming segments)
   was solely covering a single special case (return to non-conforming
   segment).
   Additionally in long mode the L bit set requires the D bit to be clear,
   as was recently pointed out for KVM by Nadav Amit
   <namit at cs.technion.ac.il>.
   Finally we also need to force the loaded selector's RPL to CPL (at
   least as long as lret/retf emulation doesn't support privilege level
   changes).
   This is CVE-2014-8595 / XSA-110.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   master commit: 1d68c1a70e00ed95ef0889cfa005379dab27b37d
   master date: 2014-11-18 14:16:23 +0100
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com> [bug 
20361745] {CVE-2014-8595}

[4.1.3-25.el5.127.56]
- AMD/intremap: Prevent use of per-device vector maps until irq logic is 
fixed
   XSA-36 changed the default vector map mode from global to per-device. 
  This is
   because a global vector map does not prevent one PCI device from 
impersonating
   another and launching a DoS on the system.
   However, the per-device vector map logic is broken for devices with 
multiple
   MSI-X vectors, which can either result in a failed ASSERT() or 
misprogramming
   of a guests interrupt remapping tables.  The core problem is not 
trivial to
   fix.
   In an effort to get AMD systems back to a non-regressed state, 
introduce a new
   type of vector map called per-device-global.  This uses per-device 
vector maps
   in the IOMMU, but uses a single used_vector map for the core IRQ logic.
   This patch is intended to be removed as soon as the per-device logic 
is fixed
   correctly.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   This patch fix bug introduced by xsa36.patch [bug 19288706]

[4.1.3-25.el5.127.55]
- x86: fix ordering of operations in destroy_irq()
   The fix for XSA-36, switching the default of vector map management to
   be per-device, exposed more readily a problem with the cleanup of these
   vector maps: dynamic_irq_cleanup() clearing desc->arch.used_vectors
   keeps the subsequently invoked clear_irq_vector() from clearing the
   bits for both the in-use and a possibly still outstanding old vector.
   Fix this by folding dynamic_irq_cleanup() into destroy_irq(), which was
   its only caller, deferring the clearing of the vector map pointer until
   after clear_irq_vector().
   Once at it, also defer resetting of desc->handler until after the loop
   around smp_mb() checking for IRQ_INPROGRESS to be clear, fixing a
   (mostly theoretical) issue with the intercation with do_IRQ(): If we
   don't defer the pointer reset, do_IRQ() could, for non-guest IRQs, call
   ->ack() and ->end() with different ->handler pointers, potentially
   leading to an IRQ remaining un-acked. The issue is mostly theoretical
   because non-guest IRQs are subject to destroy_irq() only on (boot time)
   error paths.
   As to the changed locking: Invoking clear_irq_vector() with desc->lock
   held is okay because vector_lock already nests inside desc->lock (proven
   by set_desc_affinity(), which takes vector_lock and gets called from
   various desc->handler->ack implementations, getting invoked with
   desc->lock held).
   Reported-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Keir Fraser <keir at xen.org>
   Reviewed-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: George Dunlap <george.dunlap at eu.citrix.com>
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   This patch fix bug introduced by xsa36.patch [bug 19288706]

[4.1.3-25.el5.127.54]
- AMD IOMMU: allow disabling only interrupt remapping when certain IVRS 
consistency checks fail
   After some more thought on the XSA-36 and specifically the comments we
   got regarding disabling the IOMMU in this situation altogether making
   things worse instead of better, I came to the conclusion that we can
   actually restrict the action in affected cases to just disabling
   interrupt remapping. That doesn't make the situation worse than prior
   to the XSA-36 fixes (where interrupt remapping didn't really protect
   domains from one another), but allows at least DMA isolation to still
   be utilized.
   To do so, disabling of interrupt remapping must be explicitly requested
   on the command line - respective checks will then be skipped.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Suravee Suthikulanit <suravee.suthikulpanit at amd.com>
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   This patch fix bug introduced by xsa36.patch [bug 19288706]

[4.1.3-25.el5.127.53]
- AMD IOMMU: also spot missing IO-APIC entries in IVRS table
   Apart from dealing duplicate conflicting entries, we also have to
   handle firmware omitting IO-APIC entries in IVRS altogether. Not doing
   so has resulted in c/s 26517:601139e2b0db to crash such systems during
   boot (whereas with the change here the IOMMU gets disabled just as is
   being done in the other cases, i.e. unless global tables are being
   used).
   Debugging this issue has also pointed out that the debug log output is
   pretty ugly to look at - consolidate the output, and add one extra
   item for the IVHD special entries, so that future issues are easier
   to analyze.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Tested-by: Sander Eikelenboom <linux at eikelenboom.it>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   xen-unstable changeset: 26531:e68f14b9e739
   xen-unstable date: Thu Feb 14 08:40:52 UTC 2013
   Signed-off-by: Zhenzhong Duan <zhenzhong.duan at oracle.com>
   Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
   Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
   This patch applies on top of xsa36.patch which is version 3 of the
   xen.org 4.1 patch already applied to OVM 3 [bug 19288706]