Merge remote-tracking branch 'origin/stabilization' into stabilization-user-thl-vanilla-fedorakernel-4.15.2-300.vanilla.knurd.1.fc27kernel-4.15.2-300.vanilla.knurd.1.fc26

6 files changed, 13 insertions, 300 deletions

diff --git a/filter-aarch64.sh b/filter-aarch64.sh
index d45da673f..4adc0e7e4 100644
--- a/filter-aarch64.sh
+++ b/filter-aarch64.sh
@@ -13,6 +13,6 @@ driverdirs="atm auxdisplay bcma bluetooth firewire fmc infiniband isdn leds medi
 
 ethdrvs="3com adaptec arc alteon atheros broadcom cadence calxeda chelsio cisco dec dlink emulex icplus marvell micrel myricom neterion nvidia oki-semi packetengines qlogic rdc renesas sfc silan sis smsc stmicro sun tehuti ti via wiznet xircom"
 
-drmdrvs="amd arm bridge ast exynos hisilicon i2c imx mgag200 meson msm nouveau panel radeon rockchip tegra sun4i tinydrm vc4"
+drmdrvs="amd arm ast exynos hisilicon i2c imx mgag200 meson msm nouveau panel radeon rockchip tegra sun4i tinydrm vc4"
 
 singlemods="ntb_netdev iscsi_ibft iscsi_boot_sysfs megaraid pmcraid qedi qla1280 9pnet_rdma rpcrdma nvmet-rdma nvme-rdma hid-picolcd hid-prodikeys hwa-hc hwpoison-inject target_core_user sbp_target cxgbit iw_cxgb3 iw_cxgb4 cxgb3i cxgb3i cxgb3i_ddp cxgb4i chcr"
diff --git a/filter-armv7hl.sh b/filter-armv7hl.sh
index 254893398..fdad4070b 100644
--- a/filter-armv7hl.sh
+++ b/filter-armv7hl.sh
@@ -13,6 +13,6 @@ driverdirs="atm auxdisplay bcma bluetooth firewire fmc infiniband isdn media mem
 
 ethdrvs="3com adaptec alteon altera amd atheros broadcom cadence chelsio cisco dec dlink emulex icplus mellanox micrel myricom natsemi neterion nvidia oki-semi packetengines qlogic rdc renesas sfc silan sis sun tehuti via wiznet xircom"
 
-drmdrvs="amd armada bridge ast exynos etnaviv hisilicon i2c imx meson mgag200 msm omapdrm panel nouveau radeon rockchip sti sun4i tegra tilcdc tinydrm via vc4"
+drmdrvs="amd armada ast exynos etnaviv hisilicon i2c imx meson mgag200 msm omapdrm panel nouveau radeon rockchip sti sun4i tegra tilcdc tinydrm via vc4"
 
 singlemods="ntb_netdev iscsi_ibft iscsi_boot_sysfs megaraid pmcraid qedi qla1280 9pnet_rdma rpcrdma nvmet-rdma nvme-rdma hid-picolcd hid-prodikeys hwa-hc hwpoison-inject target_core_user sbp_target cxgbit iw_cxgb3 iw_cxgb4 cxgb3i cxgb3i cxgb3i_ddp cxgb4i chcr bq27xxx_battery_hdq"
diff --git a/filter-modules.sh b/filter-modules.sh
index 972372411..f7d594341 100755
--- a/filter-modules.sh
+++ b/filter-modules.sh
@@ -32,7 +32,7 @@ fsdrvs="affs befs coda cramfs dlm ecryptfs hfs hfsplus jfs minix ncpfs nilfs2 oc
 
 netprots="6lowpan appletalk atm ax25 batman-adv bluetooth can dccp dsa ieee802154 irda l2tp mac80211 mac802154 mpls netrom nfc rds rfkill rose sctp wireless"
 
-drmdrvs="amd ast gma500 i2c i915 mgag200 nouveau radeon via "
+drmdrvs="amd ast bridge gma500 i2c i915 mgag200 nouveau radeon via "
 
 singlemods="ntb_netdev iscsi_ibft iscsi_boot_sysfs megaraid pmcraid qedi qla1280 9pnet_rdma rpcrdma nvmet-rdma nvme-rdma hid-picolcd hid-prodikeys hwa-hc hwpoison-inject hid-sensor-hub target_core_user sbp_target cxgbit iw_cxgb3 iw_cxgb4 cxgb3i cxgb3i cxgb3i_ddp cxgb4i chcr parport_serial"
 
diff --git a/kernel.spec b/kernel.spec
index ad8e77063..db055562f 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -56,7 +56,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 0
+%define stable_update 2
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -1911,6 +1911,12 @@ fi
 #
 #
 %changelog
+* Wed Feb 07 2018 Laura Abbott <labbott@redhat.com> - 4.15.2-300
+- Linux v4.15.2
+
+* Tue Feb 06 2018 Laura Abbott <labbott@redhat.com> - 4.15.1-300
+- Linux v4.15.1
+
 * Mon Feb 05 2018 Laura Abbott <labbott@redhat.com> - 4.15.0-300
 - Linux v4.15
 
diff --git a/prevent-bounds-check-bypass-via-speculative-execution.patch b/prevent-bounds-check-bypass-via-speculative-execution.patch
index 890efc149..aa19fc0d4 100644
--- a/prevent-bounds-check-bypass-via-speculative-execution.patch
+++ b/prevent-bounds-check-bypass-via-speculative-execution.patch
@@ -105,199 +105,6 @@ index fe297b599b0a..91c3071f49e5 100644
 -- 
 2.14.3
 
-From 0a9659964052448903985b38f08b3912ab65f1a9 Mon Sep 17 00:00:00 2001
-From: Mark Rutland <mark.rutland@arm.com>
-Date: Wed, 3 Jan 2018 19:47:06 +0000
-Subject: [PATCH 02/19] Documentation: document nospec helpers
-
-Document the rationale and usage of the new nospec*() helpers.
-
-Signed-off-by: Mark Rutland <mark.rutland@arm.com>
-Signed-off-by: Will Deacon <will.deacon@arm.com>
-Cc: Dan Williams <dan.j.williams@intel.com>
-Cc: Jonathan Corbet <corbet@lwn.net>
-Cc: Peter Zijlstra <peterz@infradead.org>
-Signed-off-by: Dan Williams <dan.j.williams@intel.com>
----
- Documentation/speculation.txt | 166 ++++++++++++++++++++++++++++++++++++++++++
- 1 file changed, 166 insertions(+)
- create mode 100644 Documentation/speculation.txt
-
-diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt
-new file mode 100644
-index 000000000000..748fcd4dcda4
---- /dev/null
-+++ b/Documentation/speculation.txt
-@@ -0,0 +1,166 @@
-+This document explains potential effects of speculation, and how undesirable
-+effects can be mitigated portably using common APIs.
-+
-+===========
-+Speculation
-+===========
-+
-+To improve performance and minimize average latencies, many contemporary CPUs
-+employ speculative execution techniques such as branch prediction, performing
-+work which may be discarded at a later stage.
-+
-+Typically speculative execution cannot be observed from architectural state,
-+such as the contents of registers. However, in some cases it is possible to
-+observe its impact on microarchitectural state, such as the presence or
-+absence of data in caches. Such state may form side-channels which can be
-+observed to extract secret information.
-+
-+For example, in the presence of branch prediction, it is possible for bounds
-+checks to be ignored by code which is speculatively executed. Consider the
-+following code:
-+
-+	int load_array(int *array, unsigned int idx) {
-+		if (idx >= MAX_ARRAY_ELEMS)
-+			return 0;
-+		else
-+			return array[idx];
-+	}
-+
-+Which, on arm64, may be compiled to an assembly sequence such as:
-+
-+	CMP	<idx>, #MAX_ARRAY_ELEMS
-+	B.LT	less
-+	MOV	<returnval>, #0
-+	RET
-+  less:
-+	LDR	<returnval>, [<array>, <idx>]
-+	RET
-+
-+It is possible that a CPU mis-predicts the conditional branch, and
-+speculatively loads array[idx], even if idx >= MAX_ARRAY_ELEMS. This value
-+will subsequently be discarded, but the speculated load may affect
-+microarchitectural state which can be subsequently measured.
-+
-+More complex sequences involving multiple dependent memory accesses may result
-+in sensitive information being leaked. Consider the following code, building on
-+the prior example:
-+
-+	int load_dependent_arrays(int *arr1, int *arr2, int idx) {
-+		int val1, val2,
-+
-+		val1 = load_array(arr1, idx);
-+		val2 = load_array(arr2, val1);
-+
-+		return val2;
-+	}
-+
-+Under speculation, the first call to load_array() may return the value of an
-+out-of-bounds address, while the second call will influence microarchitectural
-+state dependent on this value. This may provide an arbitrary read primitive.
-+
-+====================================
-+Mitigating speculation side-channels
-+====================================
-+
-+The kernel provides a generic API to ensure that bounds checks are respected
-+even under speculation. Architectures which are affected by speculation-based
-+side-channels are expected to implement these primitives.
-+
-+The following helpers found in <asm/barrier.h> can be used to prevent
-+information from being leaked via side-channels.
-+
-+* nospec_ptr(ptr, lo, hi)
-+
-+  Returns a sanitized pointer that is bounded by the [lo, hi) interval. When
-+  ptr < lo, or ptr >= hi, NULL is returned. Prevents an out-of-bounds pointer
-+  being propagated to code which is speculatively executed.
-+
-+  This is expected to be used by code which computes pointers to data
-+  structures, where part of the address (such as an array index) may be
-+  user-controlled.
-+
-+  This can be used to protect the earlier load_array() example:
-+
-+  int load_array(int *array, unsigned int idx)
-+  {
-+	int *elem;
-+
-+	if ((elem = nospec_ptr(array + idx, array, array + MAX_ARRAY_ELEMS)))
-+		return *elem;
-+	else
-+		return 0;
-+  }
-+
-+  This can also be used in situations where multiple fields on a structure are
-+  accessed:
-+
-+	struct foo array[SIZE];
-+	int a, b;
-+
-+	void do_thing(int idx)
-+	{
-+		struct foo *elem;
-+
-+		if ((elem = nospec_ptr(array + idx, array, array + SIZE)) {
-+			a = elem->field_a;
-+			b = elem->field_b;
-+		}
-+	}
-+
-+  It is imperative that the returned pointer is used. Pointers which are
-+  generated separately are subject to a number of potential CPU and compiler
-+  optimizations, and may still be used speculatively. For example, this means
-+  that the following sequence is unsafe:
-+
-+	struct foo array[SIZE];
-+	int a, b;
-+
-+	void do_thing(int idx)
-+	{
-+		if (nospec_ptr(array + idx, array, array + SIZE) != NULL) {
-+			// unsafe as wrong pointer is used
-+			a = array[idx].field_a;
-+			b = array[idx].field_b;
-+		}
-+	}
-+
-+  Similarly, it is unsafe to compare the returned pointer with other pointers,
-+  as this may permit the compiler to substitute one pointer with another,
-+  permitting speculation. For example, the following sequence is unsafe:
-+
-+	struct foo array[SIZE];
-+	int a, b;
-+
-+	void do_thing(int idx)
-+	{
-+		struct foo *elem = nospec_ptr(array + idx, array, array + size);
-+
-+		// unsafe due to pointer substitution
-+		if (elem == &array[idx]) {
-+			a = elem->field_a;
-+			b = elem->field_b;
-+		}
-+	}
-+
-+* nospec_array_ptr(arr, idx, sz)
-+
-+  Returns a sanitized pointer to arr[idx] only if idx falls in the [0, sz)
-+  interval. When idx < 0 or idx > sz, NULL is returned. Prevents an
-+  out-of-bounds pointer being propagated to code which is speculatively
-+  executed.
-+
-+  This is a convenience function which wraps nospec_ptr(), and has the same
-+  caveats w.r.t. the use of the returned pointer.
-+
-+  For example, this may be used as follows:
-+
-+  int load_array(int *array, unsigned int idx)
-+  {
-+	int *elem;
-+
-+	if ((elem = nospec_array_ptr(array, idx, MAX_ARRAY_ELEMS)))
-+		return *elem;
-+	else
-+		return 0;
-+  }
-+
--- 
-2.14.3
-
 From 2b98026ffeeb0b4a06c80fe39bfebd5cef4a8fa6 Mon Sep 17 00:00:00 2001
 From: Mark Rutland <mark.rutland@arm.com>
 Date: Thu, 7 Dec 2017 17:15:01 +0000
@@ -487,66 +294,6 @@ index 40f5c410fd8c..6384c90e4b72 100644
 -- 
 2.14.3
 
-From d14a4150a2f74a068247cf3846405904e21a8d2c Mon Sep 17 00:00:00 2001
-From: Dan Williams <dan.j.williams@intel.com>
-Date: Wed, 3 Jan 2018 14:51:58 -0800
-Subject: [PATCH 05/19] x86: implement nospec_barrier()
-
-The new speculative execution barrier, nospec_barrier(), ensures
-that any userspace controllable speculation doesn't cross the boundary.
-
-Any user observable speculative activity on this CPU thread before this
-point either completes, reaches a state it can no longer cause an
-observable activity, or is aborted before instructions after the barrier
-execute.
-
-In the x86 case nospec_barrier() resolves to an lfence if
-X86_FEATURE_LFENCE_RDTSC is present. Other architectures can define
-their variants.
-
-Note the expectation is that this barrier is never used directly, at
-least outside of architecture specific code. It is implied by the
-nospec_{array_ptr,ptr} macros.
-
-x86, for now, depends on the barrier for protection while other
-architectures place their speculation prevention in
-nospec_{ptr,array_ptr} when a barrier instruction is not available or
-too heavy-weight. In the x86 case lfence is not a fully serializing
-instruction so it is not as expensive as other barriers.
-
-Suggested-by: Peter Zijlstra <peterz@infradead.org>
-Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
-Suggested-by: Alan Cox <alan.cox@intel.com>
-Cc: Mark Rutland <mark.rutland@arm.com>
-Cc: Greg KH <gregkh@linuxfoundation.org>
-Cc: Thomas Gleixner <tglx@linutronix.de>
-Cc: Alan Cox <alan@linux.intel.com>
-Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
-Signed-off-by: Dan Williams <dan.j.williams@intel.com>
----
- arch/x86/include/asm/barrier.h | 6 ++++++
- 1 file changed, 6 insertions(+)
-
-diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
-index 7fb336210e1b..1148cd9f5ae7 100644
---- a/arch/x86/include/asm/barrier.h
-+++ b/arch/x86/include/asm/barrier.h
-@@ -24,6 +24,12 @@
- #define wmb()	asm volatile("sfence" ::: "memory")
- #endif
-
-+/*
-+ * CPUs without LFENCE don't really speculate much. Possibly fall back to IRET-to-self.
-+ */
-+#define __nospec_barrier() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
-+#define nospec_barrier __nospec_barrier
-+
- #ifdef CONFIG_X86_PPRO_FENCE
- #define dma_rmb()	rmb()
- #else
--- 
-2.14.3
-
 From d077f11b7fcb697af0c9419cc2273d179e6f51ad Mon Sep 17 00:00:00 2001
 From: Andi Kleen <ak@linux.intel.com>
 Date: Thu, 4 Jan 2018 13:36:20 -0800
@@ -589,7 +336,7 @@ index 574dff4d2913..9b6f20cfaeb9 100644
 +	if (__builtin_constant_p(size)) {
 +		if (unlikely(addr > limit - size))
 +			return true;
-+		nospec_barrier();
++		barrier_nospec();
 +		return false;
 +	}
 
@@ -599,7 +346,7 @@ index 574dff4d2913..9b6f20cfaeb9 100644
 +	if (unlikely(addr < size || addr > limit))
  		return true;
 -	return unlikely(addr > limit);
-+	nospec_barrier();
++	barrier_nospec();
 +	return false;
  }
 
@@ -1161,47 +908,6 @@ index 125c1eab3eaa..f72b20131a15 100644
 -- 
 2.14.3
 
-From 07a715cb9cd9e4e8bac7204a2462803bfe7ae259 Mon Sep 17 00:00:00 2001
-From: Dan Williams <dan.j.williams@intel.com>
-Date: Wed, 3 Jan 2018 13:54:04 -0800
-Subject: [PATCH 15/19] vfs, fdtable: prevent bounds-check bypass via
- speculative execution
-
-Expectedly, static analysis reports that 'fd' is a user controlled value
-that is used as a data dependency to read from the 'fdt->fd' array.  In
-order to avoid potential leaks of kernel memory values, block
-speculative execution of the instruction stream that could issue reads
-based on an invalid 'file *' returned from __fcheck_files.
-
-Based on an original patch by Elena Reshetova.
-
-Cc: Al Viro <viro@zeniv.linux.org.uk>
-Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
-Signed-off-by: Dan Williams <dan.j.williams@intel.com>
----
- include/linux/fdtable.h | 5 +++--
- 1 file changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/include/linux/fdtable.h b/include/linux/fdtable.h
-index 1c65817673db..4a147c5c2533 100644
---- a/include/linux/fdtable.h
-+++ b/include/linux/fdtable.h
-@@ -81,9 +81,10 @@ struct dentry;
- static inline struct file *__fcheck_files(struct files_struct *files, unsigned int fd)
- {
- 	struct fdtable *fdt = rcu_dereference_raw(files->fdt);
-+	struct file __rcu **fdp;
-
--	if (fd < fdt->max_fds)
--		return rcu_dereference_raw(fdt->fd[fd]);
-+	if ((fdp = nospec_array_ptr(fdt->fd, fd, fdt->max_fds)))
-+		return rcu_dereference_raw(*fdp);
- 	return NULL;
- }
-
--- 
-2.14.3
-
 From e5ef1fdb08b0d2ae0af3f725a6c4a3394af538fe Mon Sep 17 00:00:00 2001
 From: Dan Williams <dan.j.williams@intel.com>
 Date: Wed, 3 Jan 2018 13:54:05 -0800
diff --git a/sources b/sources
index 927241666..0a3ef88dd 100644
--- a/sources
+++ b/sources
@@ -1 +1,2 @@
 SHA512 (linux-4.15.tar.xz) = c00d92659df815a53dcac7dde145b742b1f20867d380c07cb09ddb3295d6ff10f8931b21ef0b09d7156923a3957b39d74d87c883300173b2e20690d2b4ec35ea
+SHA512 (patch-4.15.2.xz) = 883d36831ab6a785dda071c91502ca4401b4d4602901bb19716a390cf48ef21830ebb309fe77ec1b741519fa799de7e342df5d7689224a2989f2816bbeaded24