From ${URL} : ISSUE DESCRIPTION ================= When a guest increases the set of extended state components for a vCPU saved/ restored via XSAVE/XRSTOR (to date this can only be the upper halves of YMM registers, or AMD's LWP state) after already having touched other extended registers restored via XRSTOR (e.g. floating point or XMM ones) during its current scheduled CPU quantum, the hypervisor would make those registers accessible without discarding the values an earlier scheduled vCPU may have left in them. IMPACT ====== A malicious domain may be able to leverage this to obtain sensitive information such as cryptographic keys from another domain. VULNERABLE SYSTEMS ================== Xen 4.0 and onwards are vulnerable when run on systems with processors supporting AVX and/or LWP. Any kind of guest can exploit the vulnerability. In Xen 4.0.2 through 4.0.4 as well as in Xen 4.1.x XSAVE support is disabled by default; therefore systems running these versions are not vulnerable unless support is explicitly enabled using the "xsave" hypervisor command line option. Systems using processors supporting neither AVX nor LWP are not vulnerable. Xen 3.x and earlier are not vulnerable. MITIGATION ========== Turning off XSAVE support via the "no-xsave" hypervisor command line option will avoid the vulnerability. CREDITS ======= Jan Beulich discovered this issue. RESOLUTION ========== Applying the attached patch resolves this issue. xsa62.patch Xen 4.2.x, 4.3.x, and unstable xsa62-4.1.patch Xen 4.1.x @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
XSA 63 (CVE-2013-4355) : http://www.openwall.com/lists/oss-security/2013/09/30/1 XSA 64 (CVE-2013-4356) : http://www.openwall.com/lists/oss-security/2013/09/30/2 XSA 66 (CVE-2013-4361) : http://www.openwall.com/lists/oss-security/2013/09/30/3
CVE-2013-4361 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4361): The fbld instruction emulation in Xen 3.3.x through 4.3.x does not use the correct variable for the source effective address, which allows local HVM guests to obtain hypervisor stack information by reading the values used by the instruction. CVE-2013-4355 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4355): Xen 4.3.x and earlier does not properly handle certain errors, which allows local HVM guests to obtain hypervisor stack memory via a (1) port or (2) memory mapped I/O write or (3) other unspecified operations related to addresses without associated memory. CVE-2013-1442 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-1442): Xen 4.0 through 4.3.x, when using AVX or LWP capable CPUs, does not properly clear previous data from registers when using an XSAVE or XRSTOR to extend the state components of a saved or restored vCPU after touching other restored extended registers, which allows local guest OSes to obtain sensitive information by reading the registers.
All these do pertain to app-emulation/xen. xen-4.3.0-r1 builds fine with the patches added. xen-4.2 stable misfires with the first patch listed, xsa62.patch, despite listing Xen 4.2.x. I've emailed the xen ML however stabilising 4.3-0-r1 will make the misfire redundant. There's the matter of the arm KEYWORD to correct first Ago. testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ ls /mnt/gen2/TmpDir/portage/app-emulation/xen-4.3.0-r1/work/xen-4.3.0//xen/arch/ yields arm x86. Seeing you can't boot a xen kernel in an arm proper, is it impossible then to EVER keyword xen arm? Otherwise I prompted you months ago to add it anyway. From memory I said building it in arm proper or emulator would suffice.
Bug 477654
XSA 67 (CVE-2013-4368) : http://www.openwall.com/lists/oss-security/2013/10/10/10 XSA 68 (CVE-2013-4369) : http://www.openwall.com/lists/oss-security/2013/10/10/11 XSA 69 (CVE-2013-4370) : http://www.openwall.com/lists/oss-security/2013/10/10/13 XSA 70 (CVE-2013-4371) : http://www.openwall.com/lists/oss-security/2013/10/10/12 XSA 71 (CVE-2013-4375) : http://www.openwall.com/lists/oss-security/2013/10/10/14
CVE-2013-4356 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4356): Xen 4.3.x writes hypervisor mappings to certain shadow pagetables when live migration is performed on hosts with more than 5TB of RAM, which allows local 64-bit PV guests to read or write to invalid memory and cause a denial of service (crash).
CVE-2013-4371 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4371): Use-after-free vulnerability in the libxl_list_cpupool function in the libxl toolstack library in Xen 4.2.x and 4.3.x, when running "under memory pressure," returns the original pointer when the realloc function fails, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors. CVE-2013-4370 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4370): The ocaml binding for the xc_vcpu_getaffinity function in Xen 4.2.x and 4.3.x frees certain memory that may still be intended for use, which allows local users to cause a denial of service (heap corruption and crash) and possibly execute arbitrary code via unspecified vectors that trigger a (1) use-after-free or (2) double free. CVE-2013-4369 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4369): The xlu_vif_parse_rate function in the libxlu library in Xen 4.2.x and 4.3.x allows local users to cause a denial of service (NULL pointer dereference) by using the "@" character as the VIF rate configuration. CVE-2013-4368 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4368): The outs instruction emulation in Xen 3.1.x, 4.2.x, 4.3.x, and earlier, when using FS: or GS: segment override, uses an uninitialized variable as a segment base, which allows local 64-bit PV guests to obtain sensitive information (hypervisor stack content) via unspecified vectors related to stale data in a segment register.
XSA 72 (CVE-2013-4416) : http://seclists.org/oss-sec/2013/q4/187
XSA 73 : http://www.openwall.com/lists/oss-security/2013/11/01/2 (no cve)
(In reply to Agostino Sarubbo from comment #9) > XSA 73 : http://www.openwall.com/lists/oss-security/2013/11/01/2 (no cve) CVE number was assigned, so, small fix XSA 73 (CVE-2013-4494) : http://www.openwall.com/lists/oss-security/2013/11/01/2
CVE-2013-4494 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4494): Xen before 4.1.x, 4.2.x, and 4.3.x does not take the page_alloc_lock and grant_table.lock in the same order, which allows local guest administrators with access to multiple vcpus to cause a denial of service (host deadlock) via unspecified vectors. CVE-2013-4416 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4416): The Ocaml xenstored implementation (oxenstored) in Xen 4.1.x, 4.2.x, and 4.3.x allows local guest domains to cause a denial of service (domain shutdown) via a large message reply.
Added files/xen-CVE-2013-4368-XSA-67.patch, files/xen-CVE-2013-4375-XSA-71.patch, files/xen-CVE-2013-4494-XSA-73.patch since these pertain to app-emulation/xen, However, XSAs 68-70, 72 pertain to xen-tools, therefore it seems to me you either yet again edit the header title or whatever the right term is to incorporate app-emulation/xen-tools OR make a new sec. bug for the xsas cited above under xen-tools. Re 4.2, what a debacle. From the upstream maintainer, =============================================== It (xsa-62.patch) applies to 4.2-stable/staging. 2) Backport the xsave patches as well. http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/xstate.c;hb=12b0ee04a16194f064d5b895a844fcdc6414bfc0 should give you a good idea of the patches. http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0bda88abe18029c2bbe9dc5d07cc706bd775c9b7 is probably the main patch needed. 3) Rework the security patch yourself using .... I highly recommend option 2. =============================================== So it seems there is xen-4.2 and xen-4.2/staging. Well to me one ought suffice. xsa patch 62 fails to take and & patch 63 fails to effect a build. Though I could attempt option 3) I'm really not naturally inclined. The version 4.2 therefore has not 1, not 2, but 3 issues. 1. The tarball of xen-4.2 appears to no longer suffice. ! !! ! 2. To counter this I need backport (or is it import) a number of separate patches. ! !! ! 3. Stable 4.2 appears it should not have been made stable by virtue of Bug 486076, exposing a dep on dev-lang/ocaml-4.x. The validity of Bug 486076 impacts on 4.3 which also requires >=dev-lang/ocaml-4. This makes stabalising of 4.3.x untenable until the 'fixing' of Bug 486076. I can make a xen-4.2.2-r2.ebuild IF YOU PROMPT with a 'yep go ahead'. It will have pertinent patches 64-73, given 62 & 63 DON'T WORK, with xsa71-qemu-xen-4.2.patch & xsa73-4.2.patch, otherwise, hang it. Re issue 2, I am open to suggestions as to how to manage it, otherwise, hang it. *xen-4.3.0-r2 (06 Nov 2013) 06 Nov 2013; Ian Delaney <idella4@gentoo.org> +files/xen-CVE-2013-4368-XSA-67.patch, +files/xen-CVE-2013-4375-XSA-71.patch, +files/xen-CVE-2013-4494-XSA-73.patch, +xen-4.3.0-r2.ebuild, xen-4.2.2-r1.ebuild, xen-4.3.0-r1.ebuild: Adding more security patches to 4.3.0 from Bug #486354, 4.2.2 excluded again for now
XSA 75 (CVE-2013-4551) : http://seclists.org/oss-sec/2013/q4/249
XSA-78 (CVE-2013-6375) : http://www.openwall.com/lists/oss-security/2013/11/20/3
XSA 78 (CVE-2013-6375) : http://seclists.org/oss-sec/2013/q4/322
testuser@archtester ~/cvsPortage/gentoo-x86/app-emulation/xen $ USE="efi flask xsm" ebuild xen-4.3.0-r3.ebuild clean prepare install builds fine 4.2, is still a debacle. I have had no hints from comment 12, so it stays a debacle. The 4.3.0 is now updated. Once 4.3.0 is made stable 4.2 can be dropped off the portage map. 4.3 makes for a viable testing xen*. I asked you in irc inside a minute of your prompt if you'd care to pressure the maintainer of Bug 486076 into some action considering your activity deals totally with making ebuilds stable, and you gave NO reply. He's had just under a month to date. xen* stabilising is on hold until there is a stable form of ocaml-4 consequent to the resolution of Bug 486076 unless I totally misinterpret exchanges made in the virtualization channel in recent weeks. *xen-4.3.0-r3 (22 Nov 2013) 22 Nov 2013; Ian Delaney <idella4@gentoo.org> +files/xen-4.3-CVE-2013-6375-XSA-75.patch, +files/xen-CVE-2013-6375-XSA-78.patch, +xen-4.3.0-r3.ebuild, -xen-4.3.0-r1.ebuild, -xen-4.3.0-r2.ebuild, -xen-4.3.0.ebuild: Adding more security patches to 4.3.0 from Bug #486354, drop old
XSA 82 (CVE-2013-6885) : http://seclists.org/oss-sec/2013/q4/385
"if you are able to do a rapid bump, I will do a fast stabilization" good luck with that. *xen-4.3.0-r4 (06 Dec 2013) *xen-4.3.1-r1 (06 Dec 2013) 06 Dec 2013; Ian Delaney <idella4@gentoo.org> +files/xen-CVE-2013-6885-XSA-82.patch, +xen-4.3.0-r4.ebuild, +xen-4.3.1-r1.ebuild, -xen-4.3.0-r3.ebuild, -xen-4.3.1.ebuild: revbumps; add sec XSA-82.patch, remove old
USE ocaml has now been re-masked in or under profiles/eapi-5-files subsequent to prompting by dlan. Although far the less desired option, this makes xen* once again prone to be stabilised or is it stabilized. whatever. arch teams, excluding arm because it doesn't yet build, .... stabilise xen-4.3.1-r1.ebuild, xen-tools-4.3.1-r2, xen-pvgrub-4.3.1.ebuild.
Change; revbump of xen-tools makes now for xen-tools-4.3.1-r3.ebuild
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
glsa filed
Ping! Maintainer(s), please drop the vulnerable version.
fixed in xen-tools-4.2.3, xen-4.2.3 idella4 hilight me to specially mention that XSA-62, 63 has been solved, see bug #500530 for details
Arches and Mainter(s), Thank you for your work. Added to an existing GLSA request.
This issue was resolved and addressed in GLSA 201407-03 at http://security.gentoo.org/glsa/glsa-201407-03.xml by GLSA coordinator Mikle Kolyada (Zlogene).
