[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel46 add patch for XSA-212 from upstream

[spz <spz%pkgsrc.org@localhost>]

details:   https://anonhg.NetBSD.org/pkgsrc/rev/a34cc85297c4
branches:  trunk
changeset: 360805:a34cc85297c4
user:      spz <spz%pkgsrc.org@localhost>
date:      Sat Apr 08 12:17:58 2017 +0000

description:
add patch for XSA-212 from upstream
(http://xenbits.xen.org/xsa/advisory-212.html)

diffstat:

 sysutils/xenkernel46/Makefile              |   4 +-
 sysutils/xenkernel46/distinfo              |   3 +-
 sysutils/xenkernel46/patches/patch-XSA-212 |  89 ++++++++++++++++++++++++++++++
 3 files changed, 93 insertions(+), 3 deletions(-)

diffs (124 lines):

diff -r bb976fe36fd3 -r a34cc85297c4 sysutils/xenkernel46/Makefile
--- a/sysutils/xenkernel46/Makefile     Sat Apr 08 12:04:54 2017 +0000
+++ b/sysutils/xenkernel46/Makefile     Sat Apr 08 12:17:58 2017 +0000
@@ -1,9 +1,9 @@
-# $NetBSD: Makefile,v 1.10 2017/03/20 18:17:12 bouyer Exp $
+# $NetBSD: Makefile,v 1.11 2017/04/08 12:17:58 spz Exp $
 
 VERSION=       4.6.5
 DISTNAME=      xen-${VERSION}
 PKGNAME=       xenkernel46-${VERSION}
-#PKGREVISION=  4
+PKGREVISION=   1
 CATEGORIES=    sysutils
 MASTER_SITES=  http://bits.xensource.com/oss-xen/release/${VERSION}/
 
diff -r bb976fe36fd3 -r a34cc85297c4 sysutils/xenkernel46/distinfo
--- a/sysutils/xenkernel46/distinfo     Sat Apr 08 12:04:54 2017 +0000
+++ b/sysutils/xenkernel46/distinfo     Sat Apr 08 12:17:58 2017 +0000
@@ -1,10 +1,11 @@
-$NetBSD: distinfo,v 1.7 2017/03/20 18:17:12 bouyer Exp $
+$NetBSD: distinfo,v 1.8 2017/04/08 12:17:58 spz Exp $
 
 SHA1 (xen-4.6.5.tar.gz) = af371af662211ee1480167b6c9e35142156f3a8d
 RMD160 (xen-4.6.5.tar.gz) = 3f2468d7d3715d14842ac57b2180118ef48e93fa
 SHA512 (xen-4.6.5.tar.gz) = d3e1b16fa9d695a5fc28ca4375b8de3dfcab480437d4d0151972d9f286528c9f667841e7a6888c918c580371d6984658a8d3b92235553c8c9c052d93154547b5
 Size (xen-4.6.5.tar.gz) = 19712756 bytes
 SHA1 (patch-Config.mk) = a2a104d023cea4e551a3ad40927d4884d6c610bf
+SHA1 (patch-XSA-212) = 4637d51bcbb3b11fb0e22940f824ebacdaa15b4f
 SHA1 (patch-tools_xentrace_xenalyze.c) = ab973cb7090dc90867dcddf9ab8965f8f2f36c46
 SHA1 (patch-xen_Makefile) = be3f4577a205b23187b91319f91c50720919f70b
 SHA1 (patch-xen_arch_x86_Rules.mk) = 7b0894ba7311edb02118a021671f304cf3872154
diff -r bb976fe36fd3 -r a34cc85297c4 sysutils/xenkernel46/patches/patch-XSA-212
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel46/patches/patch-XSA-212        Sat Apr 08 12:17:58 2017 +0000
@@ -0,0 +1,89 @@
+$NetBSD: patch-XSA-212,v 1.1 2017/04/08 12:17:58 spz Exp $
+
+memory: properly check guest memory ranges in XENMEM_exchange handling
+
+The use of guest_handle_okay() here (as introduced by the XSA-29 fix)
+is insufficient here, guest_handle_subrange_okay() needs to be used
+instead.
+
+Note that the uses are okay in
+- XENMEM_add_to_physmap_batch handling due to the size field being only
+  16 bits wide,
+- livepatch_list() due to the limit of 1024 enforced on the
+  number-of-entries input (leaving aside the fact that this can be
+  called by a privileged domain only anyway),
+- compat mode handling due to counts there being limited to 32 bits,
+- everywhere else due to guest arrays being accessed sequentially from
+  index zero.
+
+This is XSA-212.
+
+Reported-by: Jann Horn <jannh%google.com@localhost>
+Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
+Reviewed-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+
+--- xen/common/memory.c
++++ xen/common/memory.c
+@@ -436,8 +436,8 @@ static long memory_exchange(XEN_GUEST_HA
+         goto fail_early;
+     }
+ 
+-    if ( !guest_handle_okay(exch.in.extent_start, exch.in.nr_extents) ||
+-         !guest_handle_okay(exch.out.extent_start, exch.out.nr_extents) )
++    if ( !guest_handle_subrange_okay(exch.in.extent_start, exch.nr_exchanged,
++                                     exch.in.nr_extents - 1) )
+     {
+         rc = -EFAULT;
+         goto fail_early;
+@@ -447,11 +447,27 @@ static long memory_exchange(XEN_GUEST_HA
+     {
+         in_chunk_order  = exch.out.extent_order - exch.in.extent_order;
+         out_chunk_order = 0;
++
++        if ( !guest_handle_subrange_okay(exch.out.extent_start,
++                                         exch.nr_exchanged >> in_chunk_order,
++                                         exch.out.nr_extents - 1) )
++        {
++            rc = -EFAULT;
++            goto fail_early;
++        }
+     }
+     else
+     {
+         in_chunk_order  = 0;
+         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
++
++        if ( !guest_handle_subrange_okay(exch.out.extent_start,
++                                         exch.nr_exchanged << out_chunk_order,
++                                         exch.out.nr_extents - 1) )
++        {
++            rc = -EFAULT;
++            goto fail_early;
++        }
+     }
+ 
+     d = rcu_lock_domain_by_any_id(exch.in.domid);
+--- xen/include/asm-x86/x86_64/uaccess.h
++++ xen/include/asm-x86/x86_64/uaccess.h
+@@ -29,8 +29,9 @@ extern void *xlat_malloc(unsigned long *
+ /*
+  * Valid if in +ve half of 48-bit address space, or above Xen-reserved area.
+  * This is also valid for range checks (addr, addr+size). As long as the
+- * start address is outside the Xen-reserved area then we will access a
+- * non-canonical address (and thus fault) before ever reaching VIRT_START.
++ * start address is outside the Xen-reserved area, sequential accesses
++ * (starting at addr) will hit a non-canonical address (and thus fault)
++ * before ever reaching VIRT_START.
+  */
+ #define __addr_ok(addr) \
+     (((unsigned long)(addr) < (1UL<<47)) || \
+@@ -40,7 +41,8 @@ extern void *xlat_malloc(unsigned long *
+     (__addr_ok(addr) || is_compat_arg_xlat_range(addr, size))
+ 
+ #define array_access_ok(addr, count, size) \
+-    (access_ok(addr, (count)*(size)))
++    (likely(((count) ?: 0UL) < (~0UL / (size))) && \
++     access_ok(addr, (count) * (size)))
+ 
+ #define __compat_addr_ok(d, addr) \
+     ((unsigned long)(addr) < HYPERVISOR_COMPAT_VIRT_START(d))