[Oraclevm-errata] OVMSA-2013-0059 Important: Oracle VM 3.2 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2013-0059

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


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



Description of changes:

[4.1.3-25.el5.22.28]
- x86: fix page refcount handling in page table pin error path
   In the original patch 7 of the series addressing XSA-45 I mistakenly
   took the addition of the call to get_page_light() in alloc_page_type()
   to cover two decrements that would happen: One for the PGT_partial bit
   that is getting set along with the call, and the other for the page
   reference the caller hold (and would be dropping on its error path).
   But of course the additional page reference is tied to the PGT_partial
   bit, and hence any caller of a function that may leave
   ->arch.old_guest_table non-NULL for error cleanup purposes has to make
   sure a respective page reference gets retained.
   Similar issues were then also spotted elsewhere: In effect all callers
   of get_page_type_preemptible() need to deal with errors in similar
   ways. To make sure error handling can work this way without leaking
   page references, a respective assertion gets added to that function.
   This is CVE-2013-1432 / XSA-58.
   Reported-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Reviewed-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com>  [bug 16949930]

[4.1.3-25.el5.22.27]
- libxl: Restrict permissions on PV console device xenstore nodes
    Matthew Daley has observed that the PV console protocol places 
sensitive host
    state into a guest writeable xenstore locations, this includes:
    - The pty used to communicate between the console backend daemon and its
    client, allowing the guest administrator to read and write arbitrary 
host
    files.
    - The output file, allowing the guest administrator to write 
arbitrary host
    files or to target arbitrary qemu chardevs which include sockets, 
udp, ptr,
    pipes etc (see -chardev in qemu(1) for a more complete list).
    - The maximum buffer size, allowing the guest administrator to 
consume more
    resources than the host administrator has configured.
    - The backend to use (qemu vs xenconsoled), potentially allowing the 
guest
    administrator to confuse host software.
    So we arrange to make the sensitive keys in the xenstore frontend 
directory
    read only for the guest. This is safe since the xenstore permissions 
model,
    unlike POSIX directory permissions, does not allow the guest to 
remove and
    recreate a node if it has write access to the containing directory.
    There are a few associated wrinkles:
    - The primary PV console is "special". It's xenstore node is not 
under the
    usual /devices/ subtree and it does not use the customary xenstore state
    machine protocol. Unfortunately its directory is used for other things,
    including the vnc-port node, which we do not want the guest to be 
able to
    write to. Rather than trying to track down all the possible 
secondary uses
    of this directory just make it r/o to the guest. All newly created
    subdirectories inherit these permissions and so are now safe by default.
    - The other serial consoles do use the customary xenstore state 
machine and
    therefore need write access to at least the "protocol" and "state" 
nodes,
    however they may also want to use arbitrary "feature-foo" nodes 
(although
    I'm not aware of any) and therefore we cannot simply lock down the 
entire
    frontend directory. Instead we add support to 
libxl__device_generic_add for
    frontend keys which are explicitly read only and use that to lock 
down the
    sensitive keys.
    - Minios' console frontend wants to write the "type" node, which it 
has no
    business doing since this is a host/toolstack level decision. This fails
    now that the node has become read only to the PV guest. Since the 
toolstack
    already writes this node just remove the attempt to set it.
    This is CVE-XXXX-XXX / XSA-57
    Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
    Conflicts (4.2 backport):
    tools/libxl/libxl.c (no vtpm, free front_ro on error in
    libxl__device_console_add)
    Conflicts (4.1 backport):
    extras/mini-os/console/xenbus.c
    tools/libxl/libxl.c
    tools/libxl/libxl_device.c
    tools/libxl/libxl_internal.h
    tools/libxl/libxl_pci.c
    tools/libxl/libxl_xshelp.c
    - minios code was in xencons_ring.c
    - many places need &gc not just gc
    - libxl__xs_writev path is not const
    - varios minor context fixups
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16949687]