[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel48 adding patch for XSA-212 from ups...

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

details:   https://anonhg.NetBSD.org/pkgsrc/rev/e4a292de27d9
branches:  trunk
changeset: 360806:e4a292de27d9
user:      spz <spz%pkgsrc.org@localhost>
date:      Sat Apr 08 12:30:42 2017 +0000

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

diffstat:

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

diffs (124 lines):

diff -r a34cc85297c4 -r e4a292de27d9 sysutils/xenkernel48/Makefile
--- a/sysutils/xenkernel48/Makefile     Sat Apr 08 12:17:58 2017 +0000
+++ b/sysutils/xenkernel48/Makefile     Sat Apr 08 12:30:42 2017 +0000
@@ -1,9 +1,9 @@
-# $NetBSD: Makefile,v 1.1 2017/03/30 09:15:09 bouyer Exp $
+# $NetBSD: Makefile,v 1.2 2017/04/08 12:30:42 spz Exp $
 
 VERSION=       4.8.0
 DISTNAME=      xen-${VERSION}
 PKGNAME=       xenkernel48-${VERSION}
-#PKGREVISION=  4
+PKGREVISION=   1
 CATEGORIES=    sysutils
 MASTER_SITES=  http://bits.xensource.com/oss-xen/release/${VERSION}/
 DIST_SUBDIR=   xen48
diff -r a34cc85297c4 -r e4a292de27d9 sysutils/xenkernel48/distinfo
--- a/sysutils/xenkernel48/distinfo     Sat Apr 08 12:17:58 2017 +0000
+++ b/sysutils/xenkernel48/distinfo     Sat Apr 08 12:30:42 2017 +0000
@@ -1,10 +1,11 @@
-$NetBSD: distinfo,v 1.1 2017/03/30 09:15:09 bouyer Exp $
+$NetBSD: distinfo,v 1.2 2017/04/08 12:30:42 spz Exp $
 
 SHA1 (xen48/xen-4.8.0.tar.gz) = c2403899b13e1e8b8da391aceecbfc932d583a88
 RMD160 (xen48/xen-4.8.0.tar.gz) = b79b1e2587caa9c6fe68d2996a4fd42f95c1fe7b
 SHA512 (xen48/xen-4.8.0.tar.gz) = 70b95553f9813573b12e52999a4df8701dec430f23c36a8dc70d25a46bb4bc9234e5b7feb74a04062af4c8d6b6bcfe947d90b2b172416206812e54bac9797454
 Size (xen48/xen-4.8.0.tar.gz) = 22499917 bytes
 SHA1 (patch-Config.mk) = abf55aa58792315e758ee3785a763cfa8c2da68f
+SHA1 (patch-XSA-212) = 4637d51bcbb3b11fb0e22940f824ebacdaa15b4f
 SHA1 (patch-xen_Makefile) = be3f4577a205b23187b91319f91c50720919f70b
 SHA1 (patch-xen_Rules.mk) = 5f33a667bae67c85d997a968c0f8b014b707d13c
 SHA1 (patch-xen_arch_x86_Rules.mk) = e2d148fb308c37c047ca41a678471217b6166977
diff -r a34cc85297c4 -r e4a292de27d9 sysutils/xenkernel48/patches/patch-XSA-212
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel48/patches/patch-XSA-212        Sat Apr 08 12:30:42 2017 +0000
@@ -0,0 +1,89 @@
+$NetBSD: patch-XSA-212,v 1.1 2017/04/08 12:30:43 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))