sys-kernel/coreos-sources: apply patch for CVE-2017-7184

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-4.10.4-r1.ebuld

@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=5
-COREOS_SOURCE_REVISION=""
+COREOS_SOURCE_REVISION="-r1"
 inherit coreos-kernel
 
 DESCRIPTION="CoreOS Linux kernel"

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-modules/coreos-modules-4.10.4-r1.ebuild

@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=5
-COREOS_SOURCE_REVISION=""
+COREOS_SOURCE_REVISION="-r1"
 inherit coreos-kernel savedconfig
 
 DESCRIPTION="CoreOS Linux kernel modules"

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/coreos-sources-4.10.4-r1.ebuild

@@ -36,4 +36,6 @@ UNIPATCH_LIST="
 	${PATCH_DIR}/z0014-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch \
 	${PATCH_DIR}/z0015-Add-arm64-coreos-verity-hash.patch \
 	${PATCH_DIR}/z0016-selinux-allow-context-mounts-on-tmpfs-ramfs-devpts-w.patch \
+	${PATCH_DIR}/z0017-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch \
+	${PATCH_DIR}/z0018-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch \
 "

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0001-Add-secure_modules-call.patch

@@ -1,7 +1,7 @@
 From b2abd80b69de4ea94e7d003a13160df562392c3a Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 9 Aug 2013 17:58:15 -0400
-Subject: [PATCH 01/16] Add secure_modules() call
+Subject: [PATCH 01/18] Add secure_modules() call
 
 Provide a single call to allow kernel code to determine whether the system
 has been configured to either disable module loading entirely or to load
@@ -59,5 +59,5 @@ index 1cd2bf3..3161532 100644
 +}
 +EXPORT_SYMBOL(secure_modules);
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0002-PCI-Lock-down-BAR-access-when-module-security-is-ena.patch

@@ -1,7 +1,7 @@
 From ea565b4c32c1078914c2dd9903d2aebf67bab0ee Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Thu, 8 Mar 2012 10:10:38 -0500
-Subject: [PATCH 02/16] PCI: Lock down BAR access when module security is
+Subject: [PATCH 02/18] PCI: Lock down BAR access when module security is
  enabled
 
 Any hardware that can potentially generate DMA has to be locked down from
@@ -114,5 +114,5 @@ index 9bf993e..922bdf6 100644
  
  	dev = pci_get_bus_and_slot(bus, dfn);
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0003-x86-Lock-down-IO-port-access-when-module-security-is.patch

@@ -1,7 +1,7 @@
 From 247ab2f0f22a52cc9b87a9e6dbd3c523cb02fd7c Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Thu, 8 Mar 2012 10:35:59 -0500
-Subject: [PATCH 03/16] x86: Lock down IO port access when module security is
+Subject: [PATCH 03/18] x86: Lock down IO port access when module security is
  enabled
 
 IO port access would permit users to gain access to PCI configuration
@@ -68,5 +68,5 @@ index 6d9cc2d..a6eca51 100644
  		return -EFAULT;
  	while (count-- > 0 && i < 65536) {
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0004-ACPI-Limit-access-to-custom_method.patch

@@ -1,7 +1,7 @@
 From 5eeb29907f925210621bd752aeca7f4826456ab3 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 9 Mar 2012 08:39:37 -0500
-Subject: [PATCH 04/16] ACPI: Limit access to custom_method
+Subject: [PATCH 04/18] ACPI: Limit access to custom_method
 
 custom_method effectively allows arbitrary access to system memory, making
 it possible for an attacker to circumvent restrictions on module loading.
@@ -27,5 +27,5 @@ index c68e724..4277938 100644
  		/* parse the table header to get the table length */
  		if (count <= sizeof(struct acpi_table_header))
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0005-asus-wmi-Restrict-debugfs-interface-when-module-load.patch

@@ -1,7 +1,7 @@
 From 30c3afa1c37c6c0adbd7cb4766d96ff2f8a3c3d2 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 9 Mar 2012 08:46:50 -0500
-Subject: [PATCH 05/16] asus-wmi: Restrict debugfs interface when module
+Subject: [PATCH 05/18] asus-wmi: Restrict debugfs interface when module
  loading is restricted
 
 We have no way of validating what all of the Asus WMI methods do on a
@@ -50,5 +50,5 @@ index 43cb680..b5d77af 100644
  				     1, asus->debug.method_id,
  				     &input, &output);
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0006-Restrict-dev-mem-and-dev-kmem-when-module-loading-is.patch

@@ -1,7 +1,7 @@
 From c8a67b57068f99a212023507ffeea874ba658b4e Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 9 Mar 2012 09:28:15 -0500
-Subject: [PATCH 06/16] Restrict /dev/mem and /dev/kmem when module loading is
+Subject: [PATCH 06/18] Restrict /dev/mem and /dev/kmem when module loading is
  restricted
 
 Allowing users to write to address space makes it possible for the kernel
@@ -38,5 +38,5 @@ index a6eca51..191b2b0 100644
  		unsigned long to_write = min_t(unsigned long, count,
  					       (unsigned long)high_memory - p);
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0007-acpi-Ignore-acpi_rsdp-kernel-parameter-when-module-l.patch

@@ -1,7 +1,7 @@
 From 5359936a69b86d5fc0893eeac402f39db3d1364a Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@redhat.com>
 Date: Mon, 25 Jun 2012 19:57:30 -0400
-Subject: [PATCH 07/16] acpi: Ignore acpi_rsdp kernel parameter when module
+Subject: [PATCH 07/18] acpi: Ignore acpi_rsdp kernel parameter when module
  loading is restricted
 
 This option allows userspace to pass the RSDP address to the kernel, which
@@ -35,5 +35,5 @@ index 57fb5f4..9174461 100644
  #endif
  
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0008-kexec-Disable-at-runtime-if-the-kernel-enforces-modu.patch

@@ -1,7 +1,7 @@
 From f7278e3a4ee1e978444966382f09fd59e8a760bd Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <mjg59@coreos.com>
 Date: Thu, 19 Nov 2015 18:55:53 -0800
-Subject: [PATCH 08/16] kexec: Disable at runtime if the kernel enforces module
+Subject: [PATCH 08/18] kexec: Disable at runtime if the kernel enforces module
  loading restrictions
 
 kexec permits the loading and execution of arbitrary code in ring 0, which
@@ -35,5 +35,5 @@ index 980936a..a0e4cb3 100644
  
  	/*
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0009-x86-Restrict-MSR-access-when-module-loading-is-restr.patch

@@ -1,7 +1,7 @@
 From e447d16529ac075611efff2a5b08a965b89f178a Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 8 Feb 2013 11:12:13 -0800
-Subject: [PATCH 09/16] x86: Restrict MSR access when module loading is
+Subject: [PATCH 09/18] x86: Restrict MSR access when module loading is
  restricted
 
 Writing to MSRs should not be allowed if module loading is restricted,
@@ -40,5 +40,5 @@ index ef68880..74937d9 100644
  			err = -EFAULT;
  			break;
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0010-Add-option-to-automatically-enforce-module-signature.patch

@@ -1,7 +1,7 @@
 From 82c969da1e430f362b44bae864bf2da8e2d3b503 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Fri, 9 Aug 2013 18:36:30 -0400
-Subject: [PATCH 10/16] Add option to automatically enforce module signatures
+Subject: [PATCH 10/18] Add option to automatically enforce module signatures
  when in Secure Boot mode
 
 UEFI Secure Boot provides a mechanism for ensuring that the firmware will
@@ -181,5 +181,5 @@ index 3161532..19fe883 100644
  {
  #ifdef CONFIG_MODULE_SIG
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0011-efi-Make-EFI_SECURE_BOOT_SIG_ENFORCE-depend-on-EFI.patch

@@ -1,7 +1,7 @@
 From 91d4b04458c069b34b0ac00b0810ea430c3af757 Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@fedoraproject.org>
 Date: Tue, 27 Aug 2013 13:28:43 -0400
-Subject: [PATCH 11/16] efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI
+Subject: [PATCH 11/18] efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI
 
 The functionality of the config option is dependent upon the platform being
 UEFI based.  Reflect this in the config deps.
@@ -26,5 +26,5 @@ index 5be38b4..efe6b42 100644
  	---help---
  	  UEFI Secure Boot provides a mechanism for ensuring that the
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0012-efi-Add-EFI_SECURE_BOOT-bit.patch

@@ -1,7 +1,7 @@
 From fe4593724b038638a71e277cb2df62750a069af8 Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@fedoraproject.org>
 Date: Tue, 27 Aug 2013 13:33:03 -0400
-Subject: [PATCH 12/16] efi: Add EFI_SECURE_BOOT bit
+Subject: [PATCH 12/18] efi: Add EFI_SECURE_BOOT bit
 
 UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
 for use with efi_enabled.
@@ -39,5 +39,5 @@ index 5b1af30..1b12c29 100644
  #ifdef CONFIG_EFI
  /*
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0013-hibernate-Disable-in-a-signed-modules-environment.patch

@@ -1,7 +1,7 @@
 From 69d98ac51018ec84515a087873082f139072fc94 Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@fedoraproject.org>
 Date: Fri, 20 Jun 2014 08:53:24 -0400
-Subject: [PATCH 13/16] hibernate: Disable in a signed modules environment
+Subject: [PATCH 13/18] hibernate: Disable in a signed modules environment
 
 There is currently no way to verify the resume image when returning
 from hibernate.  This might compromise the signed modules trust model,
@@ -35,5 +35,5 @@ index b26dbc4..ab187ad 100644
  
  /**
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0014-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch

@@ -1,7 +1,7 @@
 From ad97f1904d0ba6ce252a0af5c1601eb376e004d1 Mon Sep 17 00:00:00 2001
 From: Vito Caputo <vito.caputo@coreos.com>
 Date: Wed, 25 Nov 2015 02:59:45 -0800
-Subject: [PATCH 14/16] kbuild: derive relative path for KBUILD_SRC from CURDIR
+Subject: [PATCH 14/18] kbuild: derive relative path for KBUILD_SRC from CURDIR
 
 This enables relocating source and build trees to different roots,
 provided they stay reachable relative to one another.  Useful for
@@ -26,5 +26,5 @@ index 8df819e..65abe81 100644
  
  # Leave processing to above invocation of make
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0015-Add-arm64-coreos-verity-hash.patch

@@ -1,7 +1,7 @@
 From 3014e6df9afba9273b942cbb85c912ccb58bcbd3 Mon Sep 17 00:00:00 2001
 From: Geoff Levand <geoff@infradead.org>
 Date: Fri, 11 Nov 2016 17:28:52 -0800
-Subject: [PATCH 15/16] Add arm64 coreos verity hash
+Subject: [PATCH 15/18] Add arm64 coreos verity hash
 
 Signed-off-by: Geoff Levand <geoff@infradead.org>
 ---
@@ -25,5 +25,5 @@ index 4b1abac..a53fa57 100644
  	 * EFI will load .text onwards at the 4k section alignment
  	 * described in the PE/COFF header. To ensure that instruction
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0016-selinux-allow-context-mounts-on-tmpfs-ramfs-devpts-w.patch

@@ -1,7 +1,7 @@
 From 41afe48e7ce028e30d5da92c574a4663924281fd Mon Sep 17 00:00:00 2001
 From: Stephen Smalley <sds@tycho.nsa.gov>
 Date: Mon, 9 Jan 2017 10:07:31 -0500
-Subject: [PATCH 16/16] selinux: allow context mounts on tmpfs, ramfs, devpts
+Subject: [PATCH 16/18] selinux: allow context mounts on tmpfs, ramfs, devpts
  within user namespaces
 
 commit aad82892af261b9903cc11c55be3ecf5f0b0b4f8 ("selinux: Add support for
@@ -53,5 +53,5 @@ index d98550a..fbf2d6d 100644
  		    defcontext_sid) {
  			rc = -EACCES;
 -- 
-2.7.4
+2.9.3
 

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0017-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch

@@ -0,0 +1,49 @@
+From f541c301cbca8f4b1f0ebd31ddfa2e2b00557fc8 Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Wed, 22 Mar 2017 07:29:31 +0000
+Subject: [PATCH 17/18] xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL
+ replay_window
+
+When a new xfrm state is created during an XFRM_MSG_NEWSA call we
+validate the user supplied replay_esn to ensure that the size is valid
+and to ensure that the replay_window size is within the allocated
+buffer.  However later it is possible to update this replay_esn via a
+XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
+buffer matches the existing state and if so inject the contents.  We do
+not at this point check that the replay_window is within the allocated
+memory.  This leads to out-of-bounds reads and writes triggered by
+netlink packets.  This leads to memory corruption and the potential for
+priviledge escalation.
+
+We already attempt to validate the incoming replay information in
+xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
+is not trying to change the size of the replay state buffer which
+includes the replay_esn.  It however does not check the replay_window
+remains within that buffer.  Add validation of the contained
+replay_window.
+
+CVE-2017-7184
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ net/xfrm/xfrm_user.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
+index 9705c27..cdf887f 100644
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -415,6 +415,9 @@ static inline int xfrm_replay_verify_len(struct xfrm_replay_state_esn *replay_es
+ 	if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
+ 		return -EINVAL;
+ 
++	if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
++		return -EINVAL;
++
+ 	return 0;
+ }
+ 
+-- 
+2.9.3
+

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.10/z0018-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch

@@ -0,0 +1,39 @@
+From e8b4c221152ffb698218514866f0c0092972b2ce Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Thu, 23 Mar 2017 07:45:44 +0000
+Subject: [PATCH 18/18] xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size
+ harder
+
+Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
+wrapping issues.  To ensure we are correctly ensuring that the two ESN
+structures are the same size compare both the overall size as reported
+by xfrm_replay_state_esn_len() and the internal length are the same.
+
+CVE-2017-7184
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ net/xfrm/xfrm_user.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
+index cdf887f..40a8aa3 100644
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -412,7 +412,11 @@ static inline int xfrm_replay_verify_len(struct xfrm_replay_state_esn *replay_es
+ 	up = nla_data(rp);
+ 	ulen = xfrm_replay_state_esn_len(up);
+ 
+-	if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
++	/* Check the overall length and the internal bitmap length to avoid
++	 * potential overflow. */
++	if (nla_len(rp) < ulen ||
++	    xfrm_replay_state_esn_len(replay_esn) != ulen ||
++	    replay_esn->bmp_len != up->bmp_len)
+ 		return -EINVAL;
+ 
+ 	if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
+-- 
+2.9.3
+