Information leak on XSAVE/XRSTOR capable AMD CPUs [XSA-52, CVE-2013-2076] (#970206) Hypervisor crash due to missing exception recovery on XRSTOR [XSA-53, CVE-2013-2077] (#970204) Hypervisor crash due to missing exception recovery on XSETBV [XSA-54, CVE-2013-2078] (#970202) Multiple vulnerabilities in libelf PV kernel handling [XSA-55] (#970640)

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

XEN was updated to 4.1.5 release. It fixes various bugs and security issues.

Issues fixed separately from the 4.1.5 release :

  - bnc#824676 - Failed to setup devices for vm instance     when start multiple vms simultaneously 

  - bnc#XXXXXX - xen: CVE-2013-XXXX: XSA-61: suppress device     assignment to HVM guest when there is no IOMMU

  - Various upstream patches from Jan were integrated.

  - bnc#823786 - migrate.py support of short options dropped     by PTF

  - bnc#803712 - after live migration rcu_sched_state     detected stalls add new option xm migrate --min_remaing     <num>

  - CVE-2013-1432 / bnc#826882 - xen: XSA-58: x86: fix page     refcount handling in page table pin error path

  - CVE-2013-2211 / bnc#823608 - xen: XSA-57: libxl allows     guest write access to sensitive console related xenstore     keys

  - bnc#823011 - xen: XSA-55: Multiple vulnerabilities in     libelf PV kernel handling

  - bnc#801663 - performance of mirror lvm unsuitable for     production

  - CVE-2013-1918/ bnc#816159 - xen: CVE-2013-1918: XSA-45:
    Several long latency operations are not preemptible

  - CVE-2013-1952 / bnc#816163 - xen: CVE-2013-1952: XSA-49:
    VT-d interrupt remapping source validation flaw for     bridges

  - CVE-2013-2076 / bnc#820917 - CVE-2013-2076: xen:
    Information leak on XSAVE/XRSTOR capable AMD CPUs     (XSA-52)

  - CVE-2013-2077 / bnc#820919 - CVE-2013-2077: xen:
    Hypervisor crash due to missing exception recovery on     XRSTOR (XSA-53)

  - CVE-2013-2078 / bnc#820920 - CVE-2013-2078: xen:
    Hypervisor crash due to missing exception recovery on     XSETBV (XSA-54)

  - CVE-2013-2072 / bnc#819416 - xen: CVE-2013-2072: XSA-56:
    Buffer overflow in xencontrol Python bindings affecting     xend 

  - Update to Xen 4.1.5 c/s 23509 There were many xen.spec     file patches dropped as now being included in the 4.1.5     tarball.

  - CVE-2013-1918 / bnc#816159 - xen: XSA-45: Several long     latency operations are not preemptible

  - CVE-2013-1952 / bnc#816163 - xen: XSA-49: VT-d interrupt     remapping source validation flaw for bridges

  - bnc#809662 - can't use pv-grub to start domU (pygrub     does work)

  - CVE-2013-1917 / bnc#813673 - xen: Xen PV DoS     vulnerability with SYSENTER

  - CVE-2013-1919 / bnc#813675 - xen: Several access     permission issues with IRQs for unprivileged guests

  - CVE-2013-1920 / bnc#813677 - xen: Potential use of freed     memory in event channel operations

  - bnc#814709 - Unable to create XEN virtual machines in     SLED 11 SP2 on Kyoto

The 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.
    (CVE-2013-2076)

The remote OracleVM system is missing necessary patches to address critical security updates : please see Oracle VM Security Advisory OVMSA-2015-0068 for details.

ID	Name	Product	Family	Published	Updated	Severity
67395	Fedora 19 : xen-4.2.2-6.fc19 (2013-9986)	Nessus	Fedora Local Security Checks	7/12/2013	1/11/2021	medium
75129	openSUSE Security Update : xen (openSUSE-SU-2013:1392-1)	Nessus	SuSE Local Security Checks	6/13/2014	1/19/2021	high
79510	OracleVM 3.2 : xen (OVMSA-2013-0042)	Nessus	OracleVM Local Security Checks	11/26/2014	1/4/2021	medium
84140	OracleVM 3.2 : xen (OVMSA-2015-0068) (POODLE) (Venom)	Nessus	OracleVM Local Security Checks	6/12/2015	1/4/2021	low

Detections

Analytics

Plugins Search

medium

high

medium

low