Patches by Ian "idella4" Delaney to address security bugs #385319 and #386371.

(Portage version: 2.1.10.25/cvs/Linux x86_64)

2 files changed, 188 insertions, 0 deletions

diff --git a/app-emulation/xen/files/xen-3.4.2-CVE-2011-1583.patch b/app-emulation/xen/files/xen-3.4.2-CVE-2011-1583.patch
new file mode 100644
index 000000000000..f5cec4dbe709
--- /dev/null
+++ b/app-emulation/xen/files/xen-3.4.2-CVE-2011-1583.patch
@@ -0,0 +1,87 @@
+--- tools/libxc/xc_dom_bzimageloader.c	2009-11-10 23:12:56.000000000 +0800
++++ tools/libxc/xc_dom_bzimageloader.c	2011-10-09 20:10:08.972815311 +0800
+@@ -308,19 +308,19 @@ 
+ 
+ extern struct xc_dom_loader elf_loader;
+ 
+-static unsigned int payload_offset(struct setup_header *hdr)
++static int check_magic(struct xc_dom_image *dom, const void *magic, size_t len)
+ {
+-    unsigned int off;
++    if (len > dom->kernel_size)
++       return 0;
++    
++        return (memcmp(dom->kernel_blob, magic, len) == 0);
++ }
+ 
+-    off = (hdr->setup_sects + 1) * 512;
+-    off += hdr->payload_offset;
+-    return off;
+-}
+-
+-static int xc_dom_probe_bzimage_kernel(struct xc_dom_image *dom)
++static int check_bzimage_kernel(struct xc_dom_image *dom, int verbose)
+ {
+     struct setup_header *hdr;
+-    int ret;
++    uint64_t payload_offset, payload_length;
++    /* int ret; */
+ 
+     if ( dom->kernel_blob == NULL )
+     {
+@@ -352,20 +352,47 @@ 
+         return -EINVAL;
+     }
+ 
+-    dom->kernel_blob = dom->kernel_blob + payload_offset(hdr);
+-    dom->kernel_size = hdr->payload_length;
++     /* upcast to 64 bits to avoid overflow */
++    /* setup_sects is u8 and so cannot overflow */
++    payload_offset = (hdr->setup_sects + 1) * 512;
++    payload_offset += hdr->payload_offset;
++    payload_length = hdr->payload_length;
+ 
+-    if ( memcmp(dom->kernel_blob, "\037\213", 2) == 0 )
+-    {
++/*    if ( memcmp(dom->kernel_blob, "\037\213", 2) == 0 )
++    { 
+         ret = xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size);
+-        if ( ret == -1 )
++        if ( ret == -1 )  */
++     if ( payload_offset >= dom->kernel_size )
++     {
++         xc_dom_panic(XC_INVALID_KERNEL, "%s: payload offset overflow",
++                     __FUNCTION__);
++        return -EINVAL;
++    }
++    if ( (payload_offset + payload_length) > dom->kernel_size )
++    {
++       xc_dom_panic(XC_INVALID_KERNEL, "%s: payload length overflow",
++                     __FUNCTION__);
++    }
++
++    dom->kernel_blob = dom->kernel_blob + payload_offset;
++    dom->kernel_size = payload_length;
++    
++    if ( check_magic(dom, "\037\213", 2) )
++    {
++        if ( xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size) == -1 )
+         {
+-            xc_dom_panic(XC_INVALID_KERNEL,
+-                         "%s: unable to gzip decompress kernel\n",
+-                         __FUNCTION__);
++            if ( verbose )
++                xc_dom_panic(XC_INVALID_KERNEL, "%s: unable to decompress kernel\$n",
++                             __FUNCTION__);
+             return -EINVAL;
+         }
+     }
++    else
++    {
++        xc_dom_panic(XC_INVALID_KERNEL, "%s: unknown compression format\n",
++                     __FUNCTION__);
++           return -EINVAL;
++     }
+     else if ( memcmp(dom->kernel_blob, "\102\132\150", 3) == 0 )
+     {
+         ret = xc_try_bzip2_decode(dom, &dom->kernel_blob, &dom->kernel_size);
diff --git a/app-emulation/xen/files/xen-3.4.2-fix-__addr_ok-limit.patch b/app-emulation/xen/files/xen-3.4.2-fix-__addr_ok-limit.patch
new file mode 100644
index 000000000000..861600821f81
--- /dev/null
+++ b/app-emulation/xen/files/xen-3.4.2-fix-__addr_ok-limit.patch
@@ -0,0 +1,101 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+             Xen Security Advisory CVE-2011-2901 / XSA-4
+                        revision no.2
+        Xen <= 3.3 DoS due to incorrect virtual address validation
+
+ISSUE DESCRIPTION
+=================
+
+The x86_64 __addr_ok() macro intends to ensure that the checked
+address is either in the positive half of the 48-bit virtual address
+space, or above the Xen-reserved area. However, the current shift
+count is off-by-one, allowing full access to the "negative half" too,
+via certain hypercalls which ignore virtual-address bits [63:48].
+Vulnerable hypercalls exist only in very old versions of the
+hypervisor.
+
+VULNERABLE SYSTEMS
+==================
+
+All systems running a Xen 3.3 or earlier hypervisor with 64-bit PV
+guests with untrusted administrators are vulnerable.
+
+IMPACT
+======
+
+A malicious guest administrator on a vulnerable system is able to
+crash the host.
+
+There are no known further exploits but these have not been ruled out.
+
+RESOLUTION
+==========
+
+The attached patch resolves the issue.
+
+Alternatively, users may choose to upgrade to a more recent hypervisor
+
+PATCHES
+=======
+
+The following patch resolves this issue.
+
+Filename: fix-__addr_ok-limit.patch
+SHA1: f18bde8d276110451c608a16f577865aa1226b4f
+SHA256: 2da5aac72e1ac4849c34d38374ae456795905fd9512eef94b48fc31383c21636
+
+This patch should apply cleanly, and fix the problem, for all affected
+versions of Xen.
+
+It is harmless when applied to later hypervisors and will be included
+in the Xen unstable branch in due course.
+
+VERSION HISTORY
+===============
+
+Analysis following version 1 of this advisory (sent out to the
+predisclosure list during the embargo period) indicates that the
+actual DoS vulnerability only exists in very old hypervisors, Xen 3.3
+and earlier, contrary to previous reports.
+
+This advisory is no longer embargoed.
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.9 (GNU/Linux)
+
+iQEcBAEBAgAGBQJOYLq2AAoJEIP+FMlX6CvZLegH/26/oJBkd/WM/yYhXkzlbnIP
+MxF6Fgy96Omu8poQTanD7g1vEcM0TOLY+Kk3GGsfj4aDdEJ5Nq4ZOW8ooI0VnVcD
+7VXQqFsXPxre+eZ6g+G0AsmzdsG45C3qujUTRfGKqzYwXqjWjt9nNsdIy1Mrz8/4
+zG1uLDkN0LXnBG2Te4q8ZckYwMq8gFXHHnH35RfQ5Besu6pvJmtK3rFXETdlP12A
+JjBh7t5jsCfzvYWFQehVp8mJupuftiOBPClmVh4vrvN9gYd5rzEgB4Q9Ioiqz2qT
+2bE1zegR8NeOKBOi9xriTU8F530OdFzeWAbo7D5gyEbYdc60eNwbadcgNGLbzMg=
+=09T8
+-----END PGP SIGNATURE-----
+
+Subject: XSA-4: xen: correct limit checking in x86_64 version of __addr_ok
+
+The x86_64 __addr_ok() macro intends to ensure that the checked
+address is either in the positive half of the 48-bit virtual address
+space, or above the Xen-reserved area. However, the current shift
+count is off-by-one, allowing full access to the "negative half"
+too. Guests may exploit this to gain access to off-limits ranges.
+
+This issue has been assigned CVE-2011-2901.
+
+Signed-off-by: Laszlo Ersek <lersek@...hat.com>
+Signed-off-by: Ian Campbell <ian.campbell@...rix.com>
+
+diff --git a/xen/include/asm-x86/x86_64/uaccess.h
+b/xen/include/asm-x86/x86_64/uaccess.h
+--- a/xen/include/asm-x86/x86_64/uaccess.h
++++ b/xen/include/asm-x86/x86_64/uaccess.h
+@@ -34,7 +34,7 @@
+  * non-canonical address (and thus fault) before ever reaching VIRT_START.
+  */
+ #define __addr_ok(addr) \
+-    (((unsigned long)(addr) < (1UL<<48)) || \
++    (((unsigned long)(addr) < (1UL<<47)) || \
+      ((unsigned long)(addr) >= HYPERVISOR_VIRT_END))
+
+ #define access_ok(addr, size) \