OracleVM 3.2 : xen (OVMSA-2013-0042)
Medium Nessus Plugin ID 79510
SynopsisThe remote OracleVM host is missing one or more security updates.
DescriptionThe remote OracleVM system is missing necessary patches to address critical security updates :
- 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. (CVE-2013-2078)
- x86/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. (CVE-2013-2077)
- 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.
SolutionUpdate the affected xen / xen-devel / xen-tools packages.