[Oraclevm-errata] OVMSA-2015-0095 Important: Oracle VM 3.3 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2015-0095

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


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



Description of changes:

[4.3.0-55.el6.47.39]
- 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> [bug 21497187] 
{CVE-2015-5154}

[4.3.0-55.el6.47.38]
- ide/atapi: Fix START STOP UNIT command completion
   The command must be completed on all code paths. START STOP UNIT with
   pwrcnd set should succeed without doing anything.
   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> [bug 21497187] 
{CVE-2015-5154}

[4.3.0-55.el6.47.37]
- ide: Check array bounds before writing to io_buffer
   (CVE-2015-5154)
   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 21497187] {CVE-2015-5154}

[4.3.0-55.el6.47.36]
- 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 21497187] {CVE-2015-5154}

[4.3.0-55.el6.47.35]
- 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 21497187] {CVE-2015-5154}

[4.3.0-55.el6.47.34]
- 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>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 21249563] 
{CVE-2015-2152}