Merge remote-tracking branch 'origin/f24' into f24-user-thl-vanilla-fedorakernel-4.9.6-100.vanilla.knurd.1.fc24

6 files changed, 238 insertions, 5 deletions

diff --git a/0001-x86-efi-always-map-first-physical-page-into-EFI-page.patch b/0001-x86-efi-always-map-first-physical-page-into-EFI-page.patch
new file mode 100644
index 000000000..55baf9b52
--- /dev/null
+++ b/0001-x86-efi-always-map-first-physical-page-into-EFI-page.patch
@@ -0,0 +1,64 @@
+From fb1d9d3f95654f00c4156129f3cd90d3efe32d26 Mon Sep 17 00:00:00 2001
+From: Jiri Kosina <jkosina@suse.cz>
+Date: Wed, 25 Jan 2017 20:52:33 +0100
+Subject: [PATCH] x86/efi: always map first physical page into EFI pagetables
+
+Commit 129766708 ("x86/efi: Only map RAM into EFI page tables if in
+mixed-mode") stopped creating 1:1 mapping for all RAM in case of running
+in native 64bit mode.
+
+It turns out though that there are 64bit EFI implementations in the wild
+(this particular problem has been reported on Lenovo Yoga 710-11IKB) which
+still make use of first physical page for their own private use (which is
+what legacy BIOS used to do, but EFI specification doesn't grant any such
+right to EFI BIOS ... oh well).
+
+In case there is no mapping for this particular frame in EFI pagetables,
+as soon as firmware tries to make use of it, triple fault occurs and the
+system reboots (in case of Yoga 710-11IKB this is very early during boot).
+
+Fix that by always mapping the first page of physical memory into EFI
+pagetables.
+
+Note: just reverting 129766708 is not enough on v4.9-rc1+ to fix the
+regression on affected hardware, as commit ab72a27da ("x86/efi:
+Consolidate region mapping logic") later made the first physical frame not
+to be mapped anyway.
+
+Fixes: 129766708 ("x86/efi: Only map RAM into EFI page tables if in mixed-mode")
+Cc: stable@kernel.org # v4.8+
+Cc: Waiman Long <waiman.long@hpe.com>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Vojtech Pavlik <vojtech@ucw.cz>
+Reported-by: Hanka Pavlikova <hanka@ucw.cz>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+---
+ arch/x86/platform/efi/efi_64.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
+index 319148bd4b05..02ae2abe8b8e 100644
+--- a/arch/x86/platform/efi/efi_64.c
++++ b/arch/x86/platform/efi/efi_64.c
+@@ -269,6 +269,17 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
+ 	efi_scratch.use_pgd = true;
+ 
+ 	/*
++	 * Certain firmware versions are way too sentimental and still believe
++	 * they are exclusive and unquestionable owners of first physical page.
++	 * Create 1:1 mapping for this page to avoid triple faults during early
++	 * boot with such firmware.
++	 */
++	if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, _PAGE_RW)) {
++		pr_err("Failed to create 1:1 mapping of first page\n");
++		return 1;
++	}
++
++	/*
+ 	 * When making calls to the firmware everything needs to be 1:1
+ 	 * mapped and addressable with 32-bit pointers. Map the kernel
+ 	 * text and allocate a new stack because we can't rely on the
+-- 
+2.11.0
+
diff --git a/arm64-dma-mapping-Fix-dma_mapping_error-when-bypassing-SWIOTLB.patch b/arm64-dma-mapping-Fix-dma_mapping_error-when-bypassing-SWIOTLB.patch
new file mode 100644
index 000000000..2e7f51ec6
--- /dev/null
+++ b/arm64-dma-mapping-Fix-dma_mapping_error-when-bypassing-SWIOTLB.patch
@@ -0,0 +1,66 @@
+From patchwork Wed Jan 25 18:31:31 2017
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: [v2] arm64: dma-mapping: Fix dma_mapping_error() when bypassing
+ SWIOTLB
+From: Robin Murphy <robin.murphy@arm.com>
+X-Patchwork-Id: 9537723
+Message-Id: <840027acb4750542003dff17b4a8902ba8972754.1485368348.git.robin.murphy@arm.com>
+To: will.deacon@arm.com,
+	catalin.marinas@arm.com
+Cc: Jisheng Zhang <jszhang@marvell.com>, arnd@arndb.de,
+ konrad.wilk@oracle.com, aaro.koskinen@iki.fi, stable@vger.kernel.org,
+ linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org
+Date: Wed, 25 Jan 2017 18:31:31 +0000
+
+When bypassing SWIOTLB on small-memory systems, we need to avoid calling
+into swiotlb_dma_mapping_error() in exactly the same way as we avoid
+swiotlb_dma_supported(), because the former also relies on SWIOTLB state
+being initialised.
+
+Under the assumptions for which we skip SWIOTLB, dma_map_{single,page}()
+will only ever return the DMA-offset-adjusted physical address of the
+page passed in, thus we can report success unconditionally.
+
+Fixes: b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")
+CC: stable@vger.kernel.org
+CC: Jisheng Zhang <jszhang@marvell.com>
+Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+---
+
+v2: Get the return value the right way round this time... After some
+    careful reasoning it really is that simple.
+
+ arch/arm64/mm/dma-mapping.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
+index e04082700bb1..1ffb7d5d299a 100644
+--- a/arch/arm64/mm/dma-mapping.c
++++ b/arch/arm64/mm/dma-mapping.c
+@@ -352,6 +352,13 @@ static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
+ 	return 1;
+ }
+ 
++static int __swiotlb_dma_mapping_error(struct device *hwdev, dma_addr_t addr)
++{
++	if (swiotlb)
++		return swiotlb_dma_mapping_error(hwdev, addr);
++	return 0;
++}
++
+ static struct dma_map_ops swiotlb_dma_ops = {
+ 	.alloc = __dma_alloc,
+ 	.free = __dma_free,
+@@ -366,7 +373,7 @@ static struct dma_map_ops swiotlb_dma_ops = {
+ 	.sync_sg_for_cpu = __swiotlb_sync_sg_for_cpu,
+ 	.sync_sg_for_device = __swiotlb_sync_sg_for_device,
+ 	.dma_supported = __swiotlb_dma_supported,
+-	.mapping_error = swiotlb_dma_mapping_error,
++	.mapping_error = __swiotlb_dma_mapping_error,
+ };
+ 
+ static int __init atomic_pool_init(void)
diff --git a/config-generic b/config-generic
index 61e52e627..23bfffa1f 100644
--- a/config-generic
+++ b/config-generic
@@ -897,7 +897,7 @@ CONFIG_IPV6_VTI=m
 CONFIG_IPV6_SIT=m
 CONFIG_IPV6_SIT_6RD=y
 CONFIG_IPV6_TUNNEL=m
-# CONFIG_IPV6_GRE is not set
+CONFIG_IPV6_GRE=m
 CONFIG_IPV6_SUBTREES=y
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_IPV6_MROUTE=y
diff --git a/drm_vc4_Fix_an_integer_overflow_in_temporary_allocation_layout.patch b/drm_vc4_Fix_an_integer_overflow_in_temporary_allocation_layout.patch
new file mode 100644
index 000000000..37f012073
--- /dev/null
+++ b/drm_vc4_Fix_an_integer_overflow_in_temporary_allocation_layout.patch
@@ -0,0 +1,82 @@
+From: Eric Anholt <eric@anholt.net>
+To: dri-devel@lists.freedesktop.org
+Subject: [PATCH 1/2] drm/vc4: Fix an integer overflow in temporary
+ allocation layout.
+Date: Wed, 18 Jan 2017 07:20:49 +1100
+
+We copy the unvalidated ioctl arguments from the user into kernel
+temporary memory to run the validation from, to avoid a race where the
+user updates the unvalidate contents in between validating them and
+copying them into the validated BO.
+
+However, in setting up the layout of the kernel side, we failed to
+check one of the additions (the roundup() for shader_rec_offset)
+against integer overflow, allowing a nearly MAX_UINT value of
+bin_cl_size to cause us to under-allocate the temporary space that we
+then copy_from_user into.
+
+Reported-by: Murray McAllister <murray.mcallister@insomniasec.com>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
+---
+ drivers/gpu/drm/vc4/vc4_gem.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
+index db920771bfb5..c5fe3554858e 100644
+--- a/drivers/gpu/drm/vc4/vc4_gem.c
++++ b/drivers/gpu/drm/vc4/vc4_gem.c
+@@ -594,7 +594,8 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info *exec)
+ 					  args->shader_rec_count);
+ 	struct vc4_bo *bo;
+ 
+-	if (uniforms_offset < shader_rec_offset ||
++	if (shader_rec_offset < args->bin_cl_size ||
++	    uniforms_offset < shader_rec_offset ||
+ 	    exec_size < uniforms_offset ||
+ 	    args->shader_rec_count >= (UINT_MAX /
+ 					  sizeof(struct vc4_shader_state)) ||
+-- 
+2.11.0
+
+_______________________________________________
+dri-devel mailing list
+dri-devel@lists.freedesktop.org
+https://lists.freedesktop.org/mailman/listinfo/dri-devel
+
+From: Eric Anholt <eric@anholt.net>
+To: dri-devel@lists.freedesktop.org
+Subject: [PATCH 2/2] drm/vc4: Return -EINVAL on the overflow checks failing.
+Date: Wed, 18 Jan 2017 07:20:50 +1100
+
+By failing to set the errno, we'd continue on to trying to set up the
+RCL, and then oops on trying to dereference the tile_bo that binning
+validation should have set up.
+
+Reported-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Eric Anholt <eric@anholt.net>
+Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
+---
+ drivers/gpu/drm/vc4/vc4_gem.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
+index c5fe3554858e..ab3016982466 100644
+--- a/drivers/gpu/drm/vc4/vc4_gem.c
++++ b/drivers/gpu/drm/vc4/vc4_gem.c
+@@ -601,6 +601,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info *exec)
+ 					  sizeof(struct vc4_shader_state)) ||
+ 	    temp_size < exec_size) {
+ 		DRM_ERROR("overflow in exec arguments\n");
++		ret = -EINVAL;
+ 		goto fail;
+ 	}
+ 
+-- 
+2.11.0
+
+_______________________________________________
+dri-devel mailing list
+dri-devel@lists.freedesktop.org
+https://lists.freedesktop.org/mailman/listinfo/dri-devel
+
diff --git a/kernel.spec b/kernel.spec
index e47f6f4a4..13c4d1a72 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -59,7 +59,7 @@ Summary: The Linux kernel
 
 
 # Do we have a -stable update to apply?
-%define stable_update 5
+%define stable_update 6
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -531,6 +531,8 @@ Patch426: usb-phy-tegra-Add-38.4MHz-clock-table-entry.patch
 # Fix OMAP4 (pandaboard)
 Patch427: arm-revert-mmc-omap_hsmmc-Use-dma_request_chan-for-reque.patch
 
+Patch428: arm64-dma-mapping-Fix-dma_mapping_error-when-bypassing-SWIOTLB.patch
+
 # Not particularly happy we don't yet have a proper upstream resolution this is the right direction
 # https://www.spinics.net/lists/arm-kernel/msg535191.html
 Patch429: arm64-mm-Fix-memmap-to-be-initialized-for-the-entire-section.patch
@@ -540,10 +542,10 @@ Patch430: ARM-tegra-usb-no-reset.patch
 
 Patch431: bcm2837-initial-support.patch
 
-Patch433: bcm283x-fixes.patch
+Patch432: bcm283x-fixes.patch
 
 # http://www.spinics.net/lists/linux-mmc/msg41151.html
-Patch434: bcm283x-mmc-imp-speed.patch
+Patch433: bcm283x-mmc-imp-speed.patch
 
 Patch440: AllWinner-net-emac.patch
 
@@ -647,6 +649,12 @@ Patch851: selinux-namespace-fix.patch
 #rhbz 1390308
 Patch852: nouveau-add-maxwell-to-backlight-init.patch
 
+#CVE-2017-5576 CVE-2017-5577 rhbz 1416436 1416437 1416439
+Patch853: drm_vc4_Fix_an_integer_overflow_in_temporary_allocation_layout.patch
+
+#The saddest EFI firmware bug
+Patch854: 0001-x86-efi-always-map-first-physical-page-into-EFI-page.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2179,6 +2187,19 @@ fi
 #
 # 
 %changelog
+* Thu Jan 26 2017 Peter Robinson <pbrobinson@fedoraproject.org>
+- arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB
+
+* Thu Jan 26 2017 Laura Abbott <labbott@redhat.com> - 4.9.6-100
+- Linux v4.9.6
+- Bring in fix for bogus EFI firmware
+
+* Wed Jan 25 2017 Justin M. Forbes <jforbes@fedoraproject.org>
+- CVE-2017-5576 CVE-2017-5577 vc4 overflows (rhbz 1416436 1416437 1416439)
+
+* Mon Jan 23 2017 Justin M. Forbes <jforbes@fedoraproject.org>
+- Enable CONFIG_IPV6_GRE (rhbz 1405398)
+
 * Fri Jan 20 2017 Laura Abbott <labbott@redhat.com> - 4.9.5-100
 - Linux v4.9.5
 
diff --git a/sources b/sources
index d6f35536e..578616825 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 SHA512 (linux-4.9.tar.xz) = bf67ff812cc3cb7e5059e82cc5db0d9a7c5637f7ed9a42e4730c715bf7047c81ed3a571225f92a33ef0b6d65f35595bc32d773356646df2627da55e9bc7f1f1a
 SHA512 (perf-man-4.9.tar.gz) = d23bb3da1eadd6623fddbf4696948de7675f3dcf57c711a7427dd7ae111394f58d8f42752938bbea7cd219f1e7f6f116fc67a1c74f769711063940a065f37b99
-SHA512 (patch-4.9.5.xz) = 1da3b136478103eeabcdc02fae60ba75f3ff0a07835e47a5fbf033761fcaab2400e85184083f883b3c652f031e6834533c63c9c2b46bbe09a81ed0baa1369765
+SHA512 (patch-4.9.6.xz) = 230ab118639d19b7a473e75f5463ea9add3db8cb70fe3ba546e053fc1bd32b1d353eb1c107f5467e5f24a26c43c623cf79cf8d5a5cef85613e4da989a6c0326a