sys-kernel/coreos-sources: bump to 4.13.5

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/Manifest

@@ -1,2 +1,2 @@
 DIST linux-4.13.tar.xz 100579888 SHA256 2db3d6066c3ad93eb25b973a3d2951e022a7e975ee2fa7cbe5bddf84d9a49a2c SHA512 a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2 WHIRLPOOL d3d332e02cd3c5056c76c28cf1f81504c6f7b8f2caed7238e7dd7866747fb03154b88d8d7aec4d0eddf5760624bc7d6c5485fb52a3e32d098a2742eba96c0d05
-DIST patch-4.13.4.xz 84924 SHA256 1e34c35dfbd3b7451a7b3eb93c5e342acc006b5d1906b5e542a8f203723bb8d6 SHA512 37aa8add92ae23b627c166b878b6d8191b75c2aca3a2eb2d7ae4f55262644731ab51a3ee171186fc0b011c6c8e537686377c3e73e8928797323b0a958eeb4b6b WHIRLPOOL 0911d28889caef117092dcbdb8c0fec394507314e2224adbc585368a8f3284d5680925fad48531bd040b923f999265163b017dcefa2b922344bb6aa486ad3119
+DIST patch-4.13.5.xz 120108 SHA256 ba0cf285525e24850917c2f5cc7c2283b6509e2185bb70108f140f7ec695d57d SHA512 de55b07e52e88e3bc5af54c619933a81f535393f20712f38000bffa77ded22c7a16e70e43c28daf576bcc6cd3ad39387b8e1f430e3d22222f572113d2345df48 WHIRLPOOL cf0e094ef73563e464128d9e080b3653ea059dc8ae60f55581bbf20483ada96b71144c0862f95e15cf2281cf359c75b9be91c0b246c192ec0f5bb8b918287506

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

@@ -55,5 +55,4 @@ UNIPATCH_LIST="
 	${PATCH_DIR}/z0022-Lock-down-TIOCSSERIAL.patch \
 	${PATCH_DIR}/z0023-kbuild-derive-relative-path-for-KBUILD_SRC-from-CURD.patch \
 	${PATCH_DIR}/z0024-Add-arm64-coreos-verity-hash.patch \
-	${PATCH_DIR}/z0025-scsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nl.patch \
 "

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

@@ -1,7 +1,7 @@
-From 9f4ac2c2dcee7fd1b708f5f0b3d6c5832638fb57 Mon Sep 17 00:00:00 2001
+From f1837934545ec345d6509fe6b70d5a8e7fb48c06 Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@fedoraproject.org>
 Date: Mon, 21 Nov 2016 23:55:55 +0000
-Subject: [PATCH 01/25] efi: Add EFI_SECURE_BOOT bit
+Subject: [PATCH 01/24] efi: Add EFI_SECURE_BOOT bit
 
 UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
 that can be passed to efi_enabled() to find out whether secure boot is

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0002-Add-the-ability-to-lock-down-access-to-the-running-k.patch

@@ -1,7 +1,7 @@
-From f7364eee64c715ffe9266d8ea55d52154becf879 Mon Sep 17 00:00:00 2001
+From 07584ac35f055643fbb7d3db977edb1667761cdd Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Mon, 21 Nov 2016 23:36:17 +0000
-Subject: [PATCH 02/25] Add the ability to lock down access to the running
+Subject: [PATCH 02/24] Add the ability to lock down access to the running
  kernel image
 
 Provide a single call to allow kernel code to determine whether the system

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.patch

@@ -1,7 +1,7 @@
-From c3b1b1051e324f57e37254563bb7364a350efeb1 Mon Sep 17 00:00:00 2001
+From 50ee015df6059aafabbde1ca24cc93ed9a5d4dec Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Mon, 21 Nov 2016 23:55:55 +0000
-Subject: [PATCH 03/25] efi: Lock down the kernel if booted in secure boot mode
+Subject: [PATCH 03/24] efi: Lock down the kernel if booted in secure boot mode
 
 UEFI Secure Boot provides a mechanism for ensuring that the firmware will
 only load signed bootloaders and kernels.  Certain use cases may also

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0004-Enforce-module-signatures-if-the-kernel-is-locked-do.patch

@@ -1,7 +1,7 @@
-From d8d614fed5891ec1891e963d99396318c4a04045 Mon Sep 17 00:00:00 2001
+From 76bf27c180ae82174aa7429c24c815b7d69f4580 Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Wed, 23 Nov 2016 13:22:22 +0000
-Subject: [PATCH 04/25] Enforce module signatures if the kernel is locked down
+Subject: [PATCH 04/24] Enforce module signatures if the kernel is locked down
 
 If the kernel is locked down, require that all modules have valid
 signatures that we can verify.

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0005-Restrict-dev-mem-and-dev-kmem-when-the-kernel-is-loc.patch

@@ -1,7 +1,7 @@
-From 297df5adbc6430dccc8c7e37a296767551ce59d0 Mon Sep 17 00:00:00 2001
+From 9062089abfaf7e47d6f734d84c27c1cbea3c04c6 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:16 +0000
-Subject: [PATCH 05/25] Restrict /dev/mem and /dev/kmem when the kernel is
+Subject: [PATCH 05/24] Restrict /dev/mem and /dev/kmem when the kernel is
  locked down
 
 Allowing users to write to address space makes it possible for the kernel to

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0006-kexec-Disable-at-runtime-if-the-kernel-is-locked-dow.patch

@@ -1,7 +1,7 @@
-From b61a37800ef46d9849b6d783bcba5818ec50f821 Mon Sep 17 00:00:00 2001
+From a4a18f7a7c9f4dc853d1ed84e100bfad45ca768d Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:15 +0000
-Subject: [PATCH 06/25] kexec: Disable at runtime if the kernel is locked down
+Subject: [PATCH 06/24] kexec: Disable at runtime if the kernel is locked down
 
 kexec permits the loading and execution of arbitrary code in ring 0, which
 is something that lock-down is meant to prevent. It makes sense to disable

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0007-Copy-secure_boot-flag-in-boot-params-across-kexec-re.patch

@@ -1,7 +1,7 @@
-From e52bc57b6b14801e7b5bbd33d53d43a6020449d4 Mon Sep 17 00:00:00 2001
+From d3aa49c4e2c3fc2db64a67802d2d1ca7682f3e43 Mon Sep 17 00:00:00 2001
 From: Dave Young <dyoung@redhat.com>
 Date: Tue, 22 Nov 2016 08:46:15 +0000
-Subject: [PATCH 07/25] Copy secure_boot flag in boot params across kexec
+Subject: [PATCH 07/24] Copy secure_boot flag in boot params across kexec
  reboot
 
 Kexec reboot in case secure boot being enabled does not keep the secure

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0008-kexec_file-Disable-at-runtime-if-securelevel-has-bee.patch

@@ -1,7 +1,7 @@
-From c968d5f727c6e920190b32773dcff484eb10e738 Mon Sep 17 00:00:00 2001
+From 4f56499f69dd3492dcd4ec80bf0d39882384fedb Mon Sep 17 00:00:00 2001
 From: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>
 Date: Wed, 23 Nov 2016 13:49:19 +0000
-Subject: [PATCH 08/25] kexec_file: Disable at runtime if securelevel has been
+Subject: [PATCH 08/24] kexec_file: Disable at runtime if securelevel has been
  set
 
 When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0009-hibernate-Disable-when-the-kernel-is-locked-down.patch

@@ -1,7 +1,7 @@
-From a936ae2a13f552c581c7a467cb64695d00beac7d Mon Sep 17 00:00:00 2001
+From 73206c208c0fd2658938c75f8b2c223d64f926ac Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@fedoraproject.org>
 Date: Tue, 22 Nov 2016 08:46:15 +0000
-Subject: [PATCH 09/25] hibernate: Disable when the kernel is locked down
+Subject: [PATCH 09/24] hibernate: Disable when the kernel is locked down
 
 There is currently no way to verify the resume image when returning
 from hibernate.  This might compromise the signed modules trust model,

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0010-uswsusp-Disable-when-the-kernel-is-locked-down.patch

@@ -1,7 +1,7 @@
-From 40952a62add2d26d51d2c6ed8f16cf59ef376468 Mon Sep 17 00:00:00 2001
+From d575c18b93c029bd3042e5719af1e3536f13f90c Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <mjg59@srcf.ucam.org>
 Date: Wed, 23 Nov 2016 13:28:17 +0000
-Subject: [PATCH 10/25] uswsusp: Disable when the kernel is locked down
+Subject: [PATCH 10/24] uswsusp: Disable when the kernel is locked down
 
 uswsusp allows a user process to dump and then restore kernel state, which
 makes it possible to modify the running kernel.  Disable this if the kernel

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0011-PCI-Lock-down-BAR-access-when-the-kernel-is-locked-d.patch

@@ -1,7 +1,7 @@
-From 0233bf96a5a3399bc35f118682c70fd82e272e19 Mon Sep 17 00:00:00 2001
+From 16ad18e196811749d4d5f737e4ca0482326be131 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:15 +0000
-Subject: [PATCH 11/25] PCI: Lock down BAR access when the kernel is locked
+Subject: [PATCH 11/24] PCI: Lock down BAR access when the kernel is locked
  down
 
 Any hardware that can potentially generate DMA has to be locked down in
@@ -19,10 +19,10 @@ Signed-off-by: David Howells <dhowells@redhat.com>
  3 files changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
-index 2f3780b50723..534d6df4aec2 100644
+index 6337bce27c36..eb7c0dcca351 100644
 --- a/drivers/pci/pci-sysfs.c
 +++ b/drivers/pci/pci-sysfs.c
-@@ -881,6 +881,9 @@ static ssize_t pci_write_config(struct file *filp, struct kobject *kobj,
+@@ -888,6 +888,9 @@ static ssize_t pci_write_config(struct file *filp, struct kobject *kobj,
  	loff_t init_off = off;
  	u8 *data = (u8 *) buf;
  
@@ -32,7 +32,7 @@ index 2f3780b50723..534d6df4aec2 100644
  	if (off > dev->cfg_size)
  		return 0;
  	if (off + count > dev->cfg_size) {
-@@ -1175,6 +1178,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
+@@ -1182,6 +1185,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
  	enum pci_mmap_state mmap_type;
  	struct resource *res = &pdev->resource[bar];
  
@@ -42,7 +42,7 @@ index 2f3780b50723..534d6df4aec2 100644
  	if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
  		return -EINVAL;
  
-@@ -1258,6 +1264,9 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
+@@ -1265,6 +1271,9 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
  				     struct bin_attribute *attr, char *buf,
  				     loff_t off, size_t count)
  {

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0012-x86-Lock-down-IO-port-access-when-the-kernel-is-lock.patch

@@ -1,7 +1,7 @@
-From 1cee6d2ec1ce531436d0224c881bf6c881bfedad Mon Sep 17 00:00:00 2001
+From ad9d4a91032b313727714cbb57aa8ddfb8d80dfc Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:16 +0000
-Subject: [PATCH 12/25] x86: Lock down IO port access when the kernel is locked
+Subject: [PATCH 12/24] x86: Lock down IO port access when the kernel is locked
  down
 
 IO port access would permit users to gain access to PCI configuration

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0013-x86-Restrict-MSR-access-when-the-kernel-is-locked-do.patch

@@ -1,7 +1,7 @@
-From 6259908d97b6fddd8df26b725526386ee4519be7 Mon Sep 17 00:00:00 2001
+From f1e625e306e90405acff33c68a6285a20877de59 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:17 +0000
-Subject: [PATCH 13/25] x86: Restrict MSR access when the kernel is locked down
+Subject: [PATCH 13/24] x86: Restrict MSR access when the kernel is locked down
 
 Writing to MSRs should not be allowed if the kernel is locked down, since
 it could lead to execution of arbitrary code in kernel mode.  Based on a

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0014-asus-wmi-Restrict-debugfs-interface-when-the-kernel-.patch

@@ -1,7 +1,7 @@
-From b58e91fc00f8d64b56535e728f766aa61c09395e Mon Sep 17 00:00:00 2001
+From b94b97961964b34fa834a5a49a381ba5c40d1136 Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:16 +0000
-Subject: [PATCH 14/25] asus-wmi: Restrict debugfs interface when the kernel is
+Subject: [PATCH 14/24] asus-wmi: Restrict debugfs interface when the kernel is
  locked down
 
 We have no way of validating what all of the Asus WMI methods do on a given

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0015-ACPI-Limit-access-to-custom_method-when-the-kernel-i.patch

@@ -1,7 +1,7 @@
-From 5fab1bc15838e14d65b5cf0c345180e0f31299f4 Mon Sep 17 00:00:00 2001
+From 3c68d0f079679bbd37603e30a28fda1a51f2052d Mon Sep 17 00:00:00 2001
 From: Matthew Garrett <matthew.garrett@nebula.com>
 Date: Tue, 22 Nov 2016 08:46:16 +0000
-Subject: [PATCH 15/25] ACPI: Limit access to custom_method when the kernel is
+Subject: [PATCH 15/24] ACPI: Limit access to custom_method when the kernel is
  locked down
 
 custom_method effectively allows arbitrary access to system memory, making

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0016-acpi-Ignore-acpi_rsdp-kernel-param-when-the-kernel-h.patch

@@ -1,7 +1,7 @@
-From 0c833f13d477afe9980fad67e8eea8b0be8ab02d Mon Sep 17 00:00:00 2001
+From b422de393e6d978f5067cee5170c449dc4277f20 Mon Sep 17 00:00:00 2001
 From: Josh Boyer <jwboyer@redhat.com>
 Date: Tue, 22 Nov 2016 08:46:16 +0000
-Subject: [PATCH 16/25] acpi: Ignore acpi_rsdp kernel param when the kernel has
+Subject: [PATCH 16/24] acpi: Ignore acpi_rsdp kernel param when the kernel has
  been locked down
 
 This option allows userspace to pass the RSDP address to the kernel, which

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0017-acpi-Disable-ACPI-table-override-if-the-kernel-is-lo.patch

@@ -1,7 +1,7 @@
-From aeacbb5b071f36b680a1a726fe4cddd151ac3138 Mon Sep 17 00:00:00 2001
+From 26bcf43365c06c2ca9e3386b202c52988525d70d Mon Sep 17 00:00:00 2001
 From: Linn Crosetto <linn@hpe.com>
 Date: Wed, 23 Nov 2016 13:32:27 +0000
-Subject: [PATCH 17/25] acpi: Disable ACPI table override if the kernel is
+Subject: [PATCH 17/24] acpi: Disable ACPI table override if the kernel is
  locked down
 
 From the kernel documentation (initrd_table_override.txt):

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0018-acpi-Disable-APEI-error-injection-if-the-kernel-is-l.patch

@@ -1,7 +1,7 @@
-From 6861bab3ed1d0b05bbac760b02b141067231f8ed Mon Sep 17 00:00:00 2001
+From 0b2d6eaf44fe27ffc3f266d60acd785054c9251a Mon Sep 17 00:00:00 2001
 From: Linn Crosetto <linn@hpe.com>
 Date: Wed, 23 Nov 2016 13:39:41 +0000
-Subject: [PATCH 18/25] acpi: Disable APEI error injection if the kernel is
+Subject: [PATCH 18/24] acpi: Disable APEI error injection if the kernel is
  locked down
 
 ACPI provides an error injection mechanism, EINJ, for debugging and testing

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0019-bpf-Restrict-kernel-image-access-functions-when-the-.patch

@@ -1,7 +1,7 @@
-From 6923d52b5ff758b74f0eec2129eb0b50f688285c Mon Sep 17 00:00:00 2001
+From c03a14e840c12755863e0bb0fc3dc466cdcab734 Mon Sep 17 00:00:00 2001
 From: "Lee, Chun-Yi" <jlee@suse.com>
 Date: Wed, 23 Nov 2016 13:52:16 +0000
-Subject: [PATCH 19/25] bpf: Restrict kernel image access functions when the
+Subject: [PATCH 19/24] bpf: Restrict kernel image access functions when the
  kernel is locked down
 
 There are some bpf functions can be used to read kernel memory:

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0020-scsi-Lock-down-the-eata-driver.patch

@@ -1,7 +1,7 @@
-From a710df0f8e65d1695ea3ea66aad01ed5ddba3757 Mon Sep 17 00:00:00 2001
+From 87d86828a5c23d79d182fe08fc311980a49bb314 Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Tue, 22 Nov 2016 10:10:34 +0000
-Subject: [PATCH 20/25] scsi: Lock down the eata driver
+Subject: [PATCH 20/24] scsi: Lock down the eata driver
 
 When the kernel is running in secure boot mode, we lock down the kernel to
 prevent userspace from modifying the running kernel image.  Whilst this

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0021-Prohibit-PCMCIA-CIS-storage-when-the-kernel-is-locke.patch

@@ -1,7 +1,7 @@
-From 8b70741cefc743bff2cdead568980f510c0044ab Mon Sep 17 00:00:00 2001
+From 5674808941b241db1a075ecf6392cd2f5f963c7b Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Fri, 25 Nov 2016 14:37:45 +0000
-Subject: [PATCH 21/25] Prohibit PCMCIA CIS storage when the kernel is locked
+Subject: [PATCH 21/24] Prohibit PCMCIA CIS storage when the kernel is locked
  down
 
 Prohibit replacement of the PCMCIA Card Information Structure when the

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0022-Lock-down-TIOCSSERIAL.patch

@@ -1,7 +1,7 @@
-From 47daa615c56f5b23928028a2e7b0b3c46bed80a0 Mon Sep 17 00:00:00 2001
+From c9f901215cc9798206af8934f3e3396e812bfd36 Mon Sep 17 00:00:00 2001
 From: David Howells <dhowells@redhat.com>
 Date: Wed, 7 Dec 2016 10:28:39 +0000
-Subject: [PATCH 22/25] Lock down TIOCSSERIAL
+Subject: [PATCH 22/24] Lock down TIOCSSERIAL
 
 Lock down TIOCSSERIAL as that can be used to change the ioport and irq
 settings on a serial port.  This only appears to be an issue for the serial

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

@@ -1,7 +1,7 @@
-From 8620c5939e7e42f1dd4a06221bccb7994ba702cd Mon Sep 17 00:00:00 2001
+From 7a7e247d55502efe910eef98322fa706aa8b7ad8 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 23/25] kbuild: derive relative path for KBUILD_SRC from CURDIR
+Subject: [PATCH 23/24] 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
@@ -12,7 +12,7 @@ by some undesirable path component.
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/Makefile b/Makefile
-index 159901979dec..036e19eed4a3 100644
+index 189f1a748e4c..c44e17ddc9e1 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -142,7 +142,8 @@ $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make

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

@@ -1,7 +1,7 @@
-From 760811c7d8f73050813d1d8e41cb6a5ef98cb31d Mon Sep 17 00:00:00 2001
+From 0038c7fad4882341972286f31a15f8013f97e964 Mon Sep 17 00:00:00 2001
 From: Geoff Levand <geoff@infradead.org>
 Date: Fri, 11 Nov 2016 17:28:52 -0800
-Subject: [PATCH 24/25] Add arm64 coreos verity hash
+Subject: [PATCH 24/24] Add arm64 coreos verity hash
 
 Signed-off-by: Geoff Levand <geoff@infradead.org>
 ---

sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-sources/files/4.13/z0025-scsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nl.patch

@@ -1,60 +0,0 @@
-From 8bd2b1562182bc03feed4fc7c6afa3094c0f325b Mon Sep 17 00:00:00 2001
-From: Xin Long <lucien.xin@gmail.com>
-Date: Sun, 27 Aug 2017 20:25:26 +0800
-Subject: [PATCH 25/25] scsi: fix the issue that iscsi_if_rx doesn't parse
- nlmsg properly
-
-ChunYu found a kernel crash by syzkaller:
-
-[  651.617875] kasan: CONFIG_KASAN_INLINE enabled
-[  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
-[  651.618731] general protection fault: 0000 [#1] SMP KASAN
-[  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
-[  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
-[  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
-[  651.622762] RIP: 0010:skb_release_data+0x26c/0x590
-[...]
-[  651.627260] Call Trace:
-[  651.629156]  skb_release_all+0x4f/0x60
-[  651.629450]  consume_skb+0x1a5/0x600
-[  651.630705]  netlink_unicast+0x505/0x720
-[  651.632345]  netlink_sendmsg+0xab2/0xe70
-[  651.633704]  sock_sendmsg+0xcf/0x110
-[  651.633942]  ___sys_sendmsg+0x833/0x980
-[  651.637117]  __sys_sendmsg+0xf3/0x240
-[  651.638820]  SyS_sendmsg+0x32/0x50
-[  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2
-
-It's caused by skb_shared_info at the end of sk_buff was overwritten by
-ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.
-
-During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
-ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
-new value to skb_shinfo(SKB)->nr_frags by ev->type.
-
-This patch is to fix it by checking nlh->nlmsg_len properly there to
-avoid over accessing sk_buff.
-
-Reported-by: ChunYu Wang <chunwang@redhat.com>
-Signed-off-by: Xin Long <lucien.xin@gmail.com>
-Acked-by: Chris Leech <cleech@redhat.com>
----
- drivers/scsi/scsi_transport_iscsi.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
-index a424eaeafeb0..c55c6f3147ae 100644
---- a/drivers/scsi/scsi_transport_iscsi.c
-+++ b/drivers/scsi/scsi_transport_iscsi.c
-@@ -3689,7 +3689,7 @@ iscsi_if_rx(struct sk_buff *skb)
- 		uint32_t group;
- 
- 		nlh = nlmsg_hdr(skb);
--		if (nlh->nlmsg_len < sizeof(*nlh) ||
-+		if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) ||
- 		    skb->len < nlh->nlmsg_len) {
- 			break;
- 		}
--- 
-2.14.1
-