This bug is for the following CVE's/XSA's: CVE-2012-5634 XSA-33 CVE-2013-0151 XSA-34 CVE-2013-0152 XSA-35 CVE-2013-0154 XSA-37 CVE-2012-6075 XSA-41
ok let's make this the collection point or tracker for the related sec bugs. XSA- Nos. 20, 22, 23, 24, 26, 27, 29-35, 37 & 40 all pertain to xen package. XSA- Nos. 25 & 41 pertain to xen-tools. XSA- No. 25
(accidental save) XSA- No. 25 pertains to xen-pvgrub-4.2.0-r1. xen-4.2.0-r1 xen-tools-4.2.0-r3 xen-pvgrub-4.2.0-r1 ready & good to go for stable
Arch teams please test xen-4.2.0-r1, xen-tools-4.2.0-r3, xen-pvgrub-4.2.0-r1.
amd64 stable
x86 stable
CVE-2013-0152 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0152): Memory leak in Xen 4.2 and unstable allows local HVM guests to cause a denial of service (host memory consumption) by performing nested virtualization in a way that triggers errors that are not properly handled. CVE-2012-6075 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-6075): Buffer overflow in the e1000_receive function in the e1000 device driver (hw/e1000.c) in QEMU 1.3.0-rc2 and other versions, when the SBP and LPE flags are disabled, allows remote attackers to cause a denial of service (guest OS crash) and possibly execute arbitrary guest code via a large packet. CVE-2012-5634 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-5634): Xen 4.2.x, 4.1.x, and 4.0, when using Intel VT-d for PCI passthrough, does not properly configure VT-d when supporting a device that is behind a legacy PCI Bridge, which allows local guests to cause a denial of service to other guests by injecting an interrupt.
Added to existing GLSA request.
CVE-2013-0151 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0151): The do_hvm_op function in xen/arch/x86/hvm/hvm.c in Xen 4.2.x on the x86_32 platform does not prevent HVM_PARAM_NESTEDHVM (aka nested virtualization) operations, which allows guest OS users to cause a denial of service (long-duration page mappings and host OS crash) by leveraging administrative access to an HVM guest in a domain with a large number of VCPUs.
This issue was resolved and addressed in GLSA 201309-24 at http://security.gentoo.org/glsa/glsa-201309-24.xml by GLSA coordinator Chris Reffett (creffett).