4.17.2

4 files changed, 5 insertions, 269 deletions

diff --git a/arm64-thunderx-crypto-zip-fixes.patch b/arm64-thunderx-crypto-zip-fixes.patch
index 7f970ee30..3f40b0871 100644
--- a/arm64-thunderx-crypto-zip-fixes.patch
+++ b/arm64-thunderx-crypto-zip-fixes.patch
@@ -1,224 +1,3 @@
-From patchwork Mon Apr  9 15:45:50 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v2,1/5] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK
-From: Jan Glauber <jglauber@cavium.com>
-X-Patchwork-Id: 10331719
-Message-Id: <20180409154554.7578-2-jglauber@cavium.com>
-To: Herbert Xu <herbert@gondor.apana.org.au>
-Cc: "David S . Miller" <davem@davemloft.net>,
- linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
- Mahipal Challa <Mahipal.Challa@cavium.com>,
- Robert Richter <rrichter@cavium.com>, Jan Glauber <jglauber@cavium.com>,
- stable <stable@vger.kernel.org>
-Date: Mon,  9 Apr 2018 17:45:50 +0200
-
-Enabling virtual mapped kernel stacks breaks the thunderx_zip
-driver. On compression or decompression the executing CPU hangs
-in an endless loop. The reason for this is the usage of __pa
-by the driver which does no longer work for an address that is
-not part of the 1:1 mapping.
-
-The zip driver allocates a result struct on the stack and needs
-to tell the hardware the physical address within this struct
-that is used to signal the completion of the request.
-
-As the hardware gets the wrong address after the broken __pa
-conversion it writes to an arbitrary address. The zip driver then
-waits forever for the completion byte to contain a non-zero value.
-
-Allocating the result struct from 1:1 mapped memory resolves this
-bug.
-
-Signed-off-by: Jan Glauber <jglauber@cavium.com>
-Reviewed-by: Robert Richter <rrichter@cavium.com>
-Cc: stable <stable@vger.kernel.org> # 4.14
----
- drivers/crypto/cavium/zip/zip_crypto.c | 22 ++++++++++++++--------
- 1 file changed, 14 insertions(+), 8 deletions(-)
-
-diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c
-index 8df4d26cf9d4..b92b6e7e100f 100644
---- a/drivers/crypto/cavium/zip/zip_crypto.c
-+++ b/drivers/crypto/cavium/zip/zip_crypto.c
-@@ -124,7 +124,7 @@ int zip_compress(const u8 *src, unsigned int slen,
- 		 struct zip_kernel_ctx *zip_ctx)
- {
- 	struct zip_operation  *zip_ops   = NULL;
--	struct zip_state      zip_state;
-+	struct zip_state      *zip_state;
- 	struct zip_device     *zip = NULL;
- 	int ret;
- 
-@@ -135,20 +135,23 @@ int zip_compress(const u8 *src, unsigned int slen,
- 	if (!zip)
- 		return -ENODEV;
- 
--	memset(&zip_state, 0, sizeof(struct zip_state));
-+	zip_state = kzalloc(sizeof(*zip_state), GFP_ATOMIC);
-+	if (!zip_state)
-+		return -ENOMEM;
-+
- 	zip_ops = &zip_ctx->zip_comp;
- 
- 	zip_ops->input_len  = slen;
- 	zip_ops->output_len = *dlen;
- 	memcpy(zip_ops->input, src, slen);
- 
--	ret = zip_deflate(zip_ops, &zip_state, zip);
-+	ret = zip_deflate(zip_ops, zip_state, zip);
- 
- 	if (!ret) {
- 		*dlen = zip_ops->output_len;
- 		memcpy(dst, zip_ops->output, *dlen);
- 	}
--
-+	kfree(zip_state);
- 	return ret;
- }
- 
-@@ -157,7 +160,7 @@ int zip_decompress(const u8 *src, unsigned int slen,
- 		   struct zip_kernel_ctx *zip_ctx)
- {
- 	struct zip_operation  *zip_ops   = NULL;
--	struct zip_state      zip_state;
-+	struct zip_state      *zip_state;
- 	struct zip_device     *zip = NULL;
- 	int ret;
- 
-@@ -168,7 +171,10 @@ int zip_decompress(const u8 *src, unsigned int slen,
- 	if (!zip)
- 		return -ENODEV;
- 
--	memset(&zip_state, 0, sizeof(struct zip_state));
-+	zip_state = kzalloc(sizeof(*zip_state), GFP_ATOMIC);
-+	if (!zip_state)
-+		return -ENOMEM;
-+
- 	zip_ops = &zip_ctx->zip_decomp;
- 	memcpy(zip_ops->input, src, slen);
- 
-@@ -179,13 +185,13 @@ int zip_decompress(const u8 *src, unsigned int slen,
- 	zip_ops->input_len  = slen;
- 	zip_ops->output_len = *dlen;
- 
--	ret = zip_inflate(zip_ops, &zip_state, zip);
-+	ret = zip_inflate(zip_ops, zip_state, zip);
- 
- 	if (!ret) {
- 		*dlen = zip_ops->output_len;
- 		memcpy(dst, zip_ops->output, *dlen);
- 	}
--
-+	kfree(zip_state);
- 	return ret;
- }
- 
-From patchwork Mon Apr  9 15:45:51 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [v2,2/5] crypto: thunderx_zip: Limit result reading attempts
-From: Jan Glauber <jglauber@cavium.com>
-X-Patchwork-Id: 10331705
-Message-Id: <20180409154554.7578-3-jglauber@cavium.com>
-To: Herbert Xu <herbert@gondor.apana.org.au>
-Cc: "David S . Miller" <davem@davemloft.net>,
- linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
- Mahipal Challa <Mahipal.Challa@cavium.com>,
- Robert Richter <rrichter@cavium.com>, Jan Glauber <jglauber@cavium.com>,
- stable <stable@vger.kernel.org>
-Date: Mon,  9 Apr 2018 17:45:51 +0200
-
-After issuing a request an endless loop was used to read the
-completion state from memory which is asynchronously updated
-by the ZIP coprocessor.
-
-Add an upper bound to the retry attempts to prevent a CPU getting stuck
-forever in case of an error. Additionally, add a read memory barrier
-and a small delay between the reading attempts.
-
-Signed-off-by: Jan Glauber <jglauber@cavium.com>
-Reviewed-by: Robert Richter <rrichter@cavium.com>
-Cc: stable <stable@vger.kernel.org> # 4.14
----
- drivers/crypto/cavium/zip/common.h      | 21 +++++++++++++++++++++
- drivers/crypto/cavium/zip/zip_deflate.c |  4 ++--
- drivers/crypto/cavium/zip/zip_inflate.c |  4 ++--
- 3 files changed, 25 insertions(+), 4 deletions(-)
-
-diff --git a/drivers/crypto/cavium/zip/common.h b/drivers/crypto/cavium/zip/common.h
-index dc451e0a43c5..58fb3ed6e644 100644
---- a/drivers/crypto/cavium/zip/common.h
-+++ b/drivers/crypto/cavium/zip/common.h
-@@ -46,8 +46,10 @@
- #ifndef __COMMON_H__
- #define __COMMON_H__
- 
-+#include <linux/delay.h>
- #include <linux/init.h>
- #include <linux/interrupt.h>
-+#include <linux/io.h>
- #include <linux/kernel.h>
- #include <linux/module.h>
- #include <linux/pci.h>
-@@ -149,6 +151,25 @@ struct zip_operation {
- 	u32   sizeofzops;
- };
- 
-+static inline int zip_poll_result(union zip_zres_s *result)
-+{
-+	int retries = 1000;
-+
-+	while (!result->s.compcode) {
-+		if (!--retries) {
-+			pr_err("ZIP ERR: request timed out");
-+			return -ETIMEDOUT;
-+		}
-+		udelay(10);
-+		/*
-+		 * Force re-reading of compcode which is updated
-+		 * by the ZIP coprocessor.
-+		 */
-+		rmb();
-+	}
-+	return 0;
-+}
-+
- /* error messages */
- #define zip_err(fmt, args...) pr_err("ZIP ERR:%s():%d: " \
- 			      fmt "\n", __func__, __LINE__, ## args)
-diff --git a/drivers/crypto/cavium/zip/zip_deflate.c b/drivers/crypto/cavium/zip/zip_deflate.c
-index 9a944b8c1e29..d7133f857d67 100644
---- a/drivers/crypto/cavium/zip/zip_deflate.c
-+++ b/drivers/crypto/cavium/zip/zip_deflate.c
-@@ -129,8 +129,8 @@ int zip_deflate(struct zip_operation *zip_ops, struct zip_state *s,
- 	/* Stats update for compression requests submitted */
- 	atomic64_inc(&zip_dev->stats.comp_req_submit);
- 
--	while (!result_ptr->s.compcode)
--		continue;
-+	/* Wait for completion or error */
-+	zip_poll_result(result_ptr);
- 
- 	/* Stats update for compression requests completed */
- 	atomic64_inc(&zip_dev->stats.comp_req_complete);
-diff --git a/drivers/crypto/cavium/zip/zip_inflate.c b/drivers/crypto/cavium/zip/zip_inflate.c
-index 50cbdd83dbf2..7e0d73e2f89e 100644
---- a/drivers/crypto/cavium/zip/zip_inflate.c
-+++ b/drivers/crypto/cavium/zip/zip_inflate.c
-@@ -143,8 +143,8 @@ int zip_inflate(struct zip_operation *zip_ops, struct zip_state *s,
- 	/* Decompression requests submitted stats update */
- 	atomic64_inc(&zip_dev->stats.decomp_req_submit);
- 
--	while (!result_ptr->s.compcode)
--		continue;
-+	/* Wait for completion or error */
-+	zip_poll_result(result_ptr);
- 
- 	/* Decompression requests completed stats update */
- 	atomic64_inc(&zip_dev->stats.decomp_req_complete);
 From patchwork Mon Apr  9 15:45:52 2018
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
diff --git a/kernel.spec b/kernel.spec
index 081f52fcc..17410dd2d 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -54,7 +54,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 1
+%define stable_update 2
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -628,9 +628,6 @@ Patch502: input-rmi4-remove-the-need-for-artifical-IRQ.patch
 # https://www.spinics.net/lists/linux-acpi/msg82405.html
 Patch504: mailbox-ACPI-erroneous-error-message-when-parsing-ACPI.patch
 
-# CVE-2018-10853 rhbz 1589890 1589892
-Patch505: kvm-x86-Check-CPL-in-segmented_write_std.patch
-
 # CVE-2018-12232 rhbz 1590215 1590216
 Patch506: 0001-socket-close-race-condition-between-sock_close-and-s.patch
 
@@ -1869,6 +1866,9 @@ fi
 #
 #
 %changelog
+* Sun Jun 17 2018 Peter Robinson <pbrobinson@fedoraproject.org> 4.17.2-200
+- Linux v4.17.2
+
 * Tue Jun 12 2018 Justin M. Forbes <jforbes@fedoraproject.org> - 4.17.1-200
 - Linux v4.17.1
 - Fix CVE-2018-12232 (rhbz 1590215 1590216)
diff --git a/kvm-x86-Check-CPL-in-segmented_write_std.patch b/kvm-x86-Check-CPL-in-segmented_write_std.patch
deleted file mode 100644
index a0447d31c..000000000
--- a/kvm-x86-Check-CPL-in-segmented_write_std.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From patchwork Tue Jun  5 20:04:16 2018
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: kvm: x86: Check CPL in segmented_write_std
-From: Bandan Das <bsd@redhat.com>
-X-Patchwork-Id: 10449159
-Message-Id: <jpgtvqhuhj3.fsf@linux.bootlegged.copy>
-To: kvm@vger.kernel.org
-Cc: Paolo Bonzini <pbonzini@redhat.com>,
- Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
- Andy Lutomirski <luto@kernel.org>
-Date: Tue, 05 Jun 2018 16:04:16 -0400
-
-Certain instructions such as sgdt/sidt call segmented_write_std that
-doesn't propagate access correctly. As such, during userspace induced
-exception, the guest can incorrectly assume that the exception
-happened in the kernel and panic. The emulated write function
-segmented_write does seem to check access correctly.
-
-Reported-by: Andy Lutomirski <luto@kernel.org>
-Signed-off-by: Bandan Das <bsd@redhat.com>
----
- arch/x86/kvm/x86.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
-index 71e7cda6d014..871265f6a35f 100644
---- a/arch/x86/kvm/x86.c
-+++ b/arch/x86/kvm/x86.c
-@@ -4824,10 +4824,11 @@ int kvm_write_guest_virt_system(struct x86_emulate_ctxt *ctxt,
- 	struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
- 	void *data = val;
- 	int r = X86EMUL_CONTINUE;
-+	u32 access = (kvm_x86_ops->get_cpl(vcpu) == 3) ? PFERR_USER_MASK : 0;
- 
- 	while (bytes) {
- 		gpa_t gpa =  vcpu->arch.walk_mmu->gva_to_gpa(vcpu, addr,
--							     PFERR_WRITE_MASK,
-+							     access | PFERR_WRITE_MASK,
- 							     exception);
- 		unsigned offset = addr & (PAGE_SIZE-1);
- 		unsigned towrite = min(bytes, (unsigned)PAGE_SIZE - offset);
diff --git a/sources b/sources
index 4e821a3ae..adb894281 100644
--- a/sources
+++ b/sources
@@ -1,2 +1,2 @@
 SHA512 (linux-4.17.tar.xz) = 4d9de340a26155a89ea8773131c76220cc2057f2b5d031b467b60e8b14c1842518e2d60a863d8c695f0f7640f3f18d43826201984a238dade857b6cef79837db
-SHA512 (patch-4.17.1.xz) = 18ebb8ed8bd7b782c7e1ed057bf18260991182cbb2c20939bc31e122afdb9f4a185f3c162134f506ed608fd1f83413a29e2db8d7cee83af4c3dc1b88c892405a
+SHA512 (patch-4.17.2.xz) = d85fc2637720c19320e82fa221e0e8e2b640d2b8c6faf4678f3902ca8a634a1e2cdcac1242628da9d9500921a41c6c8cec7371098533e5035034a1faa2373c65