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

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2013-0036

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


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


Description of changes:

[4.1.3-25.el5.6.9]
- VT-d: don't permit SVT_NO_VERIFY entries for known device types
   Only in cases where we don't know what to do we should leave the IRTE
   blank (suppressing all validation), but we should always log a warning
   in those cases (as being insecure).
   This is CVE-2013-1952 / XSA-49.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: 'Zhang, Xiantao' <xiantao.zhang at intel.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16692255] 
{CVE-2013-1952}

[4.1.3-25.el5.6.8]
- x86: make page table handling error paths preemptible
   ... as they may take significant amounts of time.
   This requires cloning the tweaked continuation logic from
   do_mmuext_op() to do_mmu_update().
   Note that in mod_l[34]_entry() a negative 'preemptible' value gets
   passed to put_page_from_l[34]e() now, telling the callee to store the
   respective page in current->arch.old_guest_table (for a hypercall
   continuation to pick up), rather than carrying out the put right away.
   This is going to be made a little more explicit by a subsequent cleanup
   patch.
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-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 16692132] 
{CVE-2013-1918}

[4.1.3-25.el5.6.7]
- x86: make page table unpinning preemptible
   ... as it may take significant amounts of time.
   Since we can't re-invoke the operation in a second attempt, the
   continuation logic must be slightly tweaked so that we make sure
   do_mmuext_op() gets run one more time even when the preempted unpin
   operation was the last one in a batch.
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-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 16692132] 
{CVE-2013-1918}

[4.1.3-25.el5.6.6]
- Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16692132] 
{CVE-2013-1918}

[4.1.3-25.el5.6.5]
- x86: make vcpu_reset() preemptible
   ... as dropping the old page tables may take significant amounts of
   time.
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-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 16692132] 
{CVE-2013-1918}

[4.1.3-25.el5.6.4]
- x86: make MMUEXT_NEW_USER_BASEPTR preemptible
   ... as it may take significant amounts of time.
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-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 16692132] 
{CVE-2013-1918}

[4.1.3-25.el5.6.3]
- x86: make new_guest_cr3() preemptible
   ... as it may take significant amounts of time.
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
16692132] {CVE-2013-1918}

[4.1.3-25.el5.6.2]
- x86: make vcpu_destroy_pagetables() preemptible
   ... as it may take significant amounts of time.
   The function, being moved to mm.c as the better home for it anyway, and
   to avoid having to make a new helper function there non-static, is
   given a 'preemptible' parameter temporarily (until, in a subsequent
   patch, its other caller is also being made capable of dealing with
   preemption).
   This is part of CVE-2013-1918 / XSA-45.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Acked-by: Tim Deegan <tim at xen.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
16692132] {CVE-2013-1918}

[4.1.3-25.el5.6.1]
- Fix rcu domain locking for transitive grants
   When acquiring a transitive grant for copy then the owning domain
   needs to be locked down as well as the granting domain. This was being
   done, but the unlocking was not. The acquire code now stores the
   struct domain * of the owning domain (rather than the domid) in the
   active entry in the granting domain. The release code then does the
   unlock on the owning domain.  Note that I believe I also fixed a bug
   where, for non-transitive grants the active entry contained a
   reference to the acquiring domain rather than the granting
   domain. From my reading of the code this would stop the release code
   for transitive grants from terminating its recursion correctly.
   Signed-off-by: Paul Durrant <paul.durrant at citrix.com>
   Also, for non-transitive grants we now avoid incorrectly recursing
   in __release_grant_for_copy.
   This is CVE-2013-1964 / XSA-50.
   Reported-by: Manuel Bouyer <bouyer at antioche.eu.org>
   Tested-by: Manuel Bouyer <bouyer at antioche.eu.org>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com> [bug 
16687161] {CVE-2013-1964}