head 1.2; access; symbols pkgsrc-2017Q4:1.1.0.4 pkgsrc-2017Q4-base:1.1 pkgsrc-2017Q3:1.1.0.2; locks; strict; comment @# @; 1.2 date 2018.01.24.23.29.32; author bouyer; state dead; branches; next 1.1; commitid WktdwS8UoS8bvboA; 1.1 date 2017.10.17.08.42.30; author bouyer; state Exp; branches 1.1.2.1 1.1.4.1; next ; commitid OJpItiWkoMToMnbA; 1.1.2.1 date 2017.10.17.08.42.30; author bsiegert; state dead; branches; next 1.1.2.2; commitid fTgNkUKfFJMQdrbA; 1.1.2.2 date 2017.10.17.19.02.25; author bsiegert; state Exp; branches; next ; commitid fTgNkUKfFJMQdrbA; 1.1.4.1 date 2018.01.28.15.23.24; author bsiegert; state dead; branches; next ; commitid hLOFEOUtck6sHEoA; desc @@ 1.2 log @Update xen 4.8 packages to 4.8.3. Changes since 4.8.2: include patches from all security advisory up to and including XSA254. While there pass XEN_VENDORVERSION=nb${PKGREVISION} to make so that 'xl info' shows the NetBSD PKGREVISION. If PKGREVISION is not available, define this as 'nb0'. @ text @$NetBSD: patch-XSA238,v 1.1 2017/10/17 08:42:30 bouyer Exp $ From cdc2887076b19b39fab9faec495082586f3113df Mon Sep 17 00:00:00 2001 From: XenProject Security Team Date: Tue, 5 Sep 2017 13:41:37 +0200 Subject: x86/ioreq server: correctly handle bogus XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments Misbehaving device model can pass incorrect XEN_DMOP_map/ unmap_io_range_to_ioreq_server arguments, namely end < start when specifying address range. When this happens we hit ASSERT(s <= e) in rangeset_contains_range()/rangeset_overlaps_range() with debug builds. Production builds will not trap right away but may misbehave later while handling such bogus ranges. This is XSA-238. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Jan Beulich --- xen/arch/x86/hvm/ioreq.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index b2a8b0e986..8c8bf1f0ec 100644 --- xen/arch/x86/hvm/ioreq.c.orig +++ xen/arch/x86/hvm/ioreq.c @@@@ -820,6 +820,9 @@@@ int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id, struct hvm_ioreq_server *s; int rc; + if ( start > end ) + return -EINVAL; + spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); rc = -ENOENT; @@@@ -872,6 +875,9 @@@@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id, struct hvm_ioreq_server *s; int rc; + if ( start > end ) + return -EINVAL; + spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); rc = -ENOENT; @ 1.1 log @Update xentools48 and xenkernel48 to 4.8.2, and apply security patches up to XSA244. Keep PKGREVISION to 1 to account for the fact that it's not a stock Xen 4.8.2. Note that, unlike upstream, pv-linear-pt defaults to true, so that NetBSD PV guests (including dom0) will continue to boot without changes to boot.cfg @ text @d1 1 a1 1 $NetBSD: $ @ 1.1.4.1 log @Pullup ticket #5693 - requested by bouyer sysutils/xenkernel48: security fix sysutils/xentools48: security fix Revisions pulled up: - sysutils/xenkernel48/Makefile 1.12 - sysutils/xenkernel48/distinfo 1.6 - sysutils/xenkernel48/patches/patch-XSA231 deleted - sysutils/xenkernel48/patches/patch-XSA232 deleted - sysutils/xenkernel48/patches/patch-XSA234 deleted - sysutils/xenkernel48/patches/patch-XSA237 deleted - sysutils/xenkernel48/patches/patch-XSA238 deleted - sysutils/xenkernel48/patches/patch-XSA239 deleted - sysutils/xenkernel48/patches/patch-XSA240 deleted - sysutils/xenkernel48/patches/patch-XSA241 deleted - sysutils/xenkernel48/patches/patch-XSA242 deleted - sysutils/xenkernel48/patches/patch-XSA243 deleted - sysutils/xenkernel48/patches/patch-XSA244 deleted - sysutils/xenkernel48/patches/patch-XSA246 deleted - sysutils/xenkernel48/patches/patch-XSA247 deleted - sysutils/xenkernel48/patches/patch-XSA248 deleted - sysutils/xenkernel48/patches/patch-XSA249 deleted - sysutils/xenkernel48/patches/patch-XSA250 deleted - sysutils/xenkernel48/patches/patch-XSA251 deleted - sysutils/xenkernel48/patches/patch-XSA254-1 deleted - sysutils/xenkernel48/patches/patch-XSA254-2 deleted - sysutils/xenkernel48/patches/patch-XSA254-3 deleted - sysutils/xenkernel48/patches/patch-XSA254-4 deleted - sysutils/xentools48/Makefile 1.16 - sysutils/xentools48/distinfo 1.7-1.8 - sysutils/xentools48/patches/patch-XSA233 deleted - sysutils/xentools48/patches/patch-XSA240 deleted --- Module Name: pkgsrc Committed By: bouyer Date: Wed Jan 24 23:29:33 UTC 2018 Modified Files: pkgsrc/sysutils/xenkernel48: Makefile distinfo pkgsrc/sysutils/xentools48: Makefile distinfo Removed Files: pkgsrc/sysutils/xenkernel48/patches: patch-XSA231 patch-XSA232 patch-XSA234 patch-XSA237 patch-XSA238 patch-XSA239 patch-XSA240 patch-XSA241 patch-XSA242 patch-XSA243 patch-XSA244 patch-XSA246 patch-XSA247 patch-XSA248 patch-XSA249 patch-XSA250 patch-XSA251 patch-XSA254-1 patch-XSA254-2 patch-XSA254-3 patch-XSA254-4 pkgsrc/sysutils/xentools48/patches: patch-XSA233 patch-XSA240 Log Message: Update xen 4.8 packages to 4.8.3. Changes since 4.8.2: include patches from all security advisory up to and including XSA254. While there pass XEN_VENDORVERSION=nb${PKGREVISION} to make so that 'xl info' shows the NetBSD PKGREVISION. If PKGREVISION is not available, define this as 'nb0'. --- Module Name: pkgsrc Committed By: bouyer Date: Sat Jan 27 16:44:40 UTC 2018 Modified Files: pkgsrc/sysutils/xentools48: distinfo Log Message: Remove entries for patch-XSA233 and patch-XSA240 which have been deleted. @ text @d1 1 a1 1 $NetBSD: patch-XSA238,v 1.1 2017/10/17 08:42:30 bouyer Exp $ @ 1.1.2.1 log @file patch-XSA238 was added on branch pkgsrc-2017Q3 on 2017-10-17 19:02:25 +0000 @ text @d1 47 @ 1.1.2.2 log @Pullup ticket #5579 - requested by bouyer sysutils/xenkernel48, sysutils/xentools48: security fix Revisions pulled up: - sysutils/xenkernel48/MESSAGE 1.2 - sysutils/xenkernel48/Makefile 1.6 - sysutils/xenkernel48/distinfo 1.3 - sysutils/xenkernel48/patches/patch-XSA-212 deleted - sysutils/xenkernel48/patches/patch-XSA231 1.1 - sysutils/xenkernel48/patches/patch-XSA232 1.1 - sysutils/xenkernel48/patches/patch-XSA234 1.1 - sysutils/xenkernel48/patches/patch-XSA237 1.1 - sysutils/xenkernel48/patches/patch-XSA238 1.1 - sysutils/xenkernel48/patches/patch-XSA239 1.1 - sysutils/xenkernel48/patches/patch-XSA240 1.1 - sysutils/xenkernel48/patches/patch-XSA241 1.1 - sysutils/xenkernel48/patches/patch-XSA242 1.1 - sysutils/xenkernel48/patches/patch-XSA243 1.1 - sysutils/xenkernel48/patches/patch-XSA244 1.1 - sysutils/xentools48/Makefile 1.8 - sysutils/xentools48/distinfo 1.4 - sysutils/xentools48/patches/patch-XSA-211-1 deleted - sysutils/xentools48/patches/patch-XSA-211-2 deleted - sysutils/xentools48/patches/patch-XSA233 1.1 - sysutils/xentools48/patches/patch-XSA240 1.1 --- Module Name: pkgsrc Committed By: bouyer Date: Tue Oct 17 08:42:30 UTC 2017 Modified Files: pkgsrc/sysutils/xenkernel48: MESSAGE Makefile distinfo pkgsrc/sysutils/xentools48: Makefile distinfo Added Files: pkgsrc/sysutils/xenkernel48/patches: patch-XSA231 patch-XSA232 patch-XSA234 patch-XSA237 patch-XSA238 patch-XSA239 patch-XSA240 patch-XSA241 patch-XSA242 patch-XSA243 patch-XSA244 pkgsrc/sysutils/xentools48/patches: patch-XSA233 patch-XSA240 Removed Files: pkgsrc/sysutils/xenkernel48/patches: patch-XSA-212 pkgsrc/sysutils/xentools48/patches: patch-XSA-211-1 patch-XSA-211-2 Log Message: Update xentools48 and xenkernel48 to 4.8.2, and apply security patches up to XSA244. Keep PKGREVISION to 1 to account for the fact that it's not a stock Xen 4.8.2. Note that, unlike upstream, pv-linear-pt defaults to true, so that NetBSD PV guests (including dom0) will continue to boot without changes to boot.cfg @ text @a0 47 $NetBSD: patch-XSA238,v 1.1 2017/10/17 08:42:30 bouyer Exp $ From cdc2887076b19b39fab9faec495082586f3113df Mon Sep 17 00:00:00 2001 From: XenProject Security Team Date: Tue, 5 Sep 2017 13:41:37 +0200 Subject: x86/ioreq server: correctly handle bogus XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments Misbehaving device model can pass incorrect XEN_DMOP_map/ unmap_io_range_to_ioreq_server arguments, namely end < start when specifying address range. When this happens we hit ASSERT(s <= e) in rangeset_contains_range()/rangeset_overlaps_range() with debug builds. Production builds will not trap right away but may misbehave later while handling such bogus ranges. This is XSA-238. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Jan Beulich --- xen/arch/x86/hvm/ioreq.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index b2a8b0e986..8c8bf1f0ec 100644 --- xen/arch/x86/hvm/ioreq.c.orig +++ xen/arch/x86/hvm/ioreq.c @@@@ -820,6 +820,9 @@@@ int hvm_map_io_range_to_ioreq_server(struct domain *d, ioservid_t id, struct hvm_ioreq_server *s; int rc; + if ( start > end ) + return -EINVAL; + spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); rc = -ENOENT; @@@@ -872,6 +875,9 @@@@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id, struct hvm_ioreq_server *s; int rc; + if ( start > end ) + return -EINVAL; + spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock); rc = -ENOENT; @