[Oraclevm-errata] OVMSA-2012-0051 Important: Oracle VM 3.1 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2012-0051

The following updated rpms for Oracle VM 3.1 have been uploaded to the 
Unbreakable Linux Network:

x86_64:
xen-4.1.2-18.el5.24.x86_64.rpm
xen-devel-4.1.2-18.el5.24.x86_64.rpm
xen-tools-4.1.2-18.el5.24.x86_64.rpm


SRPMS:
http://oss.oracle.com/oraclevm/server/3.1/SRPMS-updates/xen-4.1.2-18.el5.24.src.rpm



Description of changes:

[4.1.2-18.el5.24]
- libxc: builder: limit maximum size of kernel/ramdisk.
   Allowing user supplied kernels of arbitrary sizes, especially during
   decompression, can swallow up dom0 memory leading to either virtual
   address space exhaustion in the builder process or allocation
   failures/OOM killing of both toolstack and unrelated processes.
   We disable these checks when building in a stub domain for pvgrub
   since this uses the guest's own memory and is isolated.
   Decompression of gzip compressed kernels and ramdisks has been safe
   since 14954:58205257517d (Xen 3.1.0 onwards).
   This is XSA-25 / CVE-2012-4544.
   Also make explicit checks for buffer overflows in various
   decompression routines. These were already ruled out due to other
   properties of the code but check them as a belt-and-braces measure.
   Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
   [ Includes 25589:60f09d1ab1fe for CVE-2012-2625]
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14812640] 
{CVE-2012-4544}

[4.1.2-18.el5.23]
- compat/gnttab: Prevent infinite loop in compat code
   c/s 20281:95ea2052b41b, which introduces Grant Table version 2
   hypercalls introduces a vulnerability whereby the compat hypercall
   handler can fall into an infinite loop.
   If the watchdog is enabled, Xen will die after the timeout.
   This is a security problem, XSA-24 / CVE-2012-4539.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809075] 
{CVE-2012-4539}

[4.1.2-18.el5.22]
- xen/mm/shadow: check toplevel pagetables are present before unhooking 
them.
   If the guest has not fully populated its top-level PAE entries when 
it calls
   HVMOP_pagetable_dying, the shadow code could try to unhook entries from
   MFN 0.  Add a check to avoid that case.
   This issue was introduced by c/s 21239:b9d2db109cf5.
   This is a security problem, XSA-23 / CVE-2012-4538.
   Signed-off-by: Tim Deegan <tim at xen.org>
   Tested-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809055] 
{CVE-2012-4538}

[4.1.2-18.el5.21]
- x86/physmap: Prevent incorrect updates of m2p mappings
   In certain conditions, such as low memory, set_p2m_entry() can fail.
   Currently, the p2m and m2p tables will get out of sync because we still
   update the m2p table after the p2m update has failed.
   If that happens, subsequent guest-invoked memory operations can cause
   BUG()s and ASSERT()s to kill Xen.
   This is fixed by only updating the m2p table iff the p2m was
   successfully updated.
   This is a security problem, XSA-22 / CVE-2012-4537.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Acked-by: Ian Jackson <ian.jackson at eu.citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14809010] 
{CVE-2012-4537}

[4.1.2-18.el5.20]
- x86/physdev: Range check pirq parameter from guests
   Otherwise Xen will read beyond either end of the struct
   domain.arch.pirq_emuirq array, usually resulting in a fatal page fault.
   This vulnerability was introduced by c/s 23241:d21100f1d00e, which adds
   a call to domain_pirq_to_emuirq() which uses the guest provided pirq
   value before range checking it, and was fixed by c/s 23573:584c2e5e03d9
   which changed the behaviour of the domain_pirq_to_emuirq() macro to use
   radix trees instead of a flat array.
   This is XSA-21 / CVE-2012-4536.
  Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 14808999] 
{CVE-2012-4536}

[4.1.2-18.el5.19]
- VCPU/timers: Prevent overflow in calculations, leading to DoS 
vulnerability
   The timer action for a vcpu periodic timer is to calculate the next
   expiry time, and to reinsert itself into the timer queue.  If the
   deadline ends up in the past, Xen never leaves __do_softirq().  The
   affected PCPU will stay in an infinite loop until Xen is killed by the
   watchdog (if enabled).
   This is a security problem, XSA-20 / CVE-2012-4535.
   Signed-off-by: Andrew Cooper <andrew.cooper3 at citrix.com>
   Acked-by: Ian Campbell <ian.campbell at citrix.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
14808914] {CVE-2012-4535}

[4.1.2-18.el5.18]
- Correct RTC time offset update error for HVM guest
   changeset 24947:b198ada9689d
   Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
   Backported-by: Joe Jin <joe.jin at oracle.com> [bug 15846562]

[4.1.2-18.el5.17]
- always release vm running lock on VM shutdown
   Before this patch, when xend restarted, the VM running lock will not 
be released
   on shutdown, so the VM could never start again.
   Talked with Junjie, we recommend always releasing the lock on VM 
shutdown. So
   even when xend restarted, there should be no stale lock leaving there.
   Backported-by: Joe Jin <joe.jin at oracle.com>
   Signed-off-by: Zhigang Wang <zhigang.x.wang at oracle.com>
   Signed-off-by: Adnan Misherfi <adnan.misherfi at oracle.com>
   Signed-off-by: Junjie Wei <junjie.wei at oracle.com>
   Signed-off-by: Kurt Hackel <kurt.hackel at oracle.com> [bug 14799467]