[Oraclevm-errata] OVMSA-2013-0043 Important: Oracle VM 3.1 xen security update

[Errata Announcements for Oracle VM]

Oracle VM Security Advisory OVMSA-2013-0043

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.54.x86_64.rpm
xen-devel-4.1.2-18.el5.54.x86_64.rpm
xen-tools-4.1.2-18.el5.54.x86_64.rpm


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



Description of changes:

[4.1.2-18.el5.54]
- x86/xsave: properly check guest input to XSETBV
   Other than the HVM emulation path, the PV case so far failed to check
   that YMM state requires SSE state to be enabled, allowing for a #GP to
   occur upon passing the inputs to XSETBV inside the hypervisor.
   This is CVE-2013-2078 / XSA-54.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16822734] 
{CVE-2013-2078}

[4.1.2-18.el5.53]
- 86/xsave: recover from faults on XRSTOR
   Just like FXRSTOR, XRSTOR can raise #GP if bad content is being passed
   to it in the memory block (i.e. aspects not under the control of the
   hypervisor, other than e.g. proper alignment of the block).
   Also correct the comment explaining why FXRSTOR needs exception
   recovery code to not wrongly state that this can only be a result of
   the control tools passing a bad image.
   This is CVE-2013-2077 / XSA-53.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16822670] 
{CVE-2013-2077}

[4.1.2-18.el5.52]
- x86/xsave: fix information leak on AMD CPUs
   Just like for FXSAVE/FXRSTOR, XSAVE/XRSTOR also don't save/restore the
   last instruction and operand pointers as well as the last opcode if
   there's no pending unmasked exception (see CVE-2006-1056 and commit
   9747:4d667a139318).
   While the FXSR solution sits in the save path, I prefer to have this in
   the restore path because there the handling is simpler (namely in the
   context of the pending changes to properly save the selector values for
   32-bit guest code).
   Also this is using FFREE instead of EMMS, as it doesn't seem unlikely
   that in the future we may see CPUs with x87 and SSE/AVX but no MMX
   support. The goal here anyway is just to avoid an FPU stack overflow.
   I would have preferred to use FFREEP instead of FFREE (freeing two
   stack slots at once), but AMD doesn't document that instruction.
   This is CVE-2013-2076 / XSA-52.
   Signed-off-by: Jan Beulich <jbeulich at suse.com>
   Signed-off-by: Chuck Anderson <chuck.anderson at oracle.com>
   Reviewed-by: John Haxby <john.haxby at oracle.com> [bug 16822521] 
{CVE-2013-2076}