4.12.8-300.fc26.gnu

6 files changed, 168 insertions, 8 deletions

diff --git a/freed-ora/current/f26/iio-race-fix.patch b/freed-ora/current/f26/iio-race-fix.patch
new file mode 100644
index 000000000..2661fa535
--- /dev/null
+++ b/freed-ora/current/f26/iio-race-fix.patch
@@ -0,0 +1,83 @@
+From eafad73ed3851707fa6e3124a255fc049ff9545d Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Sat, 12 Aug 2017 09:09:21 -0700
+Subject: iio: hid-sensor-trigger: Fix the race with user space powering up
+ sensors
+
+It has been reported for a while that with iio-sensor-proxy service the
+rotation only works after one suspend/resume cycle. This required a wait
+in the systemd unit file to avoid race. I found a Yoga 900 where I could
+reproduce this.
+
+The problem scenerio is:
+- During sensor driver init, enable run time PM and also set a
+  auto-suspend for 3 seconds.
+	This result in one runtime resume. But there is a check to avoid
+a powerup in this sequence, but rpm is active
+- User space iio-sensor-proxy tries to power up the sensor. Since rpm is
+  active it will simply return. But sensors were not actually
+powered up in the prior sequence, so actaully the sensors will not work
+- After 3 seconds the auto suspend kicks
+
+If we add a wait in systemd service file to fire iio-sensor-proxy after
+3 seconds, then now everything will work as the runtime resume will
+actually powerup the sensor as this is a user request.
+
+To avoid this:
+- Remove the check to match user requested state, this will cause a
+  brief powerup, but if the iio-sensor-proxy starts immediately it will
+still work as the sensors are ON.
+- Also move the autosuspend delay to place when user requested turn off
+  of sensors, like after user finished raw read or buffer disable
+
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Tested-by: Bastien Nocera <hadess@hadess.net>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+---
+ drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+index 16ade0a..0e4b379 100644
+--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
++++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+@@ -111,8 +111,6 @@ static int _hid_sensor_power_state(struct hid_sensor_common *st, bool state)
+ 	s32 poll_value = 0;
+ 
+ 	if (state) {
+-		if (!atomic_read(&st->user_requested_state))
+-			return 0;
+ 		if (sensor_hub_device_open(st->hsdev))
+ 			return -EIO;
+ 
+@@ -161,6 +159,9 @@ static int _hid_sensor_power_state(struct hid_sensor_common *st, bool state)
+ 				       &report_val);
+ 	}
+ 
++	pr_debug("HID_SENSOR %s set power_state %d report_state %d\n",
++		 st->pdev->name, state_val, report_val);
++
+ 	sensor_hub_get_feature(st->hsdev, st->power_state.report_id,
+ 			       st->power_state.index,
+ 			       sizeof(state_val), &state_val);
+@@ -182,6 +183,7 @@ int hid_sensor_power_state(struct hid_sensor_common *st, bool state)
+ 		ret = pm_runtime_get_sync(&st->pdev->dev);
+ 	else {
+ 		pm_runtime_mark_last_busy(&st->pdev->dev);
++		pm_runtime_use_autosuspend(&st->pdev->dev);
+ 		ret = pm_runtime_put_autosuspend(&st->pdev->dev);
+ 	}
+ 	if (ret < 0) {
+@@ -285,8 +287,6 @@ int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
+ 	/* Default to 3 seconds, but can be changed from sysfs */
+ 	pm_runtime_set_autosuspend_delay(&attrb->pdev->dev,
+ 					 3000);
+-	pm_runtime_use_autosuspend(&attrb->pdev->dev);
+-
+ 	return ret;
+ error_unreg_trigger:
+ 	iio_trigger_unregister(trig);
+-- 
+cgit v1.1
+
diff --git a/freed-ora/current/f26/kernel.spec b/freed-ora/current/f26/kernel.spec
index d2ad30c2b..570a74563 100644
--- a/freed-ora/current/f26/kernel.spec
+++ b/freed-ora/current/f26/kernel.spec
@@ -92,7 +92,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 7
+%define stable_update 8
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -723,6 +723,12 @@ Patch706: Fix-for-module-sig-verification.patch
 # rhbz 1462381
 Patch707: Back-out-qxl-atomic-delay.patch
 
+# CVE-2017-12134 rhbz 1477656 1481786
+Patch708: xsa229.patch
+
+# request for bug fix
+Patch709: iio-race-fix.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2392,6 +2398,18 @@ fi
 #
 #
 %changelog
+* Thu Aug 17 2017 Alexandre Oliva <lxoliva@fsfla.org> -libre
+- GNU Linux-libre 4.12.8-gnu.
+
+* Thu Aug 17 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.12.8-300
+- Linux v4.12.8
+
+* Wed Aug 16 2017 Laura Abbott <labbott@redhat.com>
+- Fix for iio race
+
+* Wed Aug 16 2017 Justin M. Forbes <jforbes@fedoraproject.org>
+- Fix xen CVE-2017-12134 (rhbz 1477656 1481786)
+
 * Wed Aug 16 2017 Alexandre Oliva <lxoliva@fsfla.org> -libre
 - GNU Linux-libre 4.12.7-gnu.
 
diff --git a/freed-ora/current/f26/patch-4.12-gnu-4.12.7-gnu.xz.sign b/freed-ora/current/f26/patch-4.12-gnu-4.12.7-gnu.xz.sign
deleted file mode 100644
index 07e266891..000000000
--- a/freed-ora/current/f26/patch-4.12-gnu-4.12.7-gnu.xz.sign
+++ /dev/null
@@ -1,6 +0,0 @@
------BEGIN PGP SIGNATURE-----
-
-iF0EABECAB0WIQRHRALIxYLa++OJxCe8t8+Hfn1HpwUCWZDXGAAKCRC8t8+Hfn1H
-p29EAJ9QsVebKZTWCHQs1TzrqDv3t/SGtwCeON70smwFd9siusnPXf4f9fBU8SQ=
-=I3aq
------END PGP SIGNATURE-----
diff --git a/freed-ora/current/f26/patch-4.12-gnu-4.12.8-gnu.xz.sign b/freed-ora/current/f26/patch-4.12-gnu-4.12.8-gnu.xz.sign
new file mode 100644
index 000000000..ca850d4de
--- /dev/null
+++ b/freed-ora/current/f26/patch-4.12-gnu-4.12.8-gnu.xz.sign
@@ -0,0 +1,6 @@
+-----BEGIN PGP SIGNATURE-----
+
+iF0EABECAB0WIQRHRALIxYLa++OJxCe8t8+Hfn1HpwUCWZVetAAKCRC8t8+Hfn1H
+pzGFAKCKcuYEGAPUP7niyg14btWWzZkfxwCcDTK0vpOiVcLA6OkwEOixNyHiWe8=
+=yiYh
+-----END PGP SIGNATURE-----
diff --git a/freed-ora/current/f26/sources b/freed-ora/current/f26/sources
index bff562c6e..9161c099a 100644
--- a/freed-ora/current/f26/sources
+++ b/freed-ora/current/f26/sources
@@ -1,3 +1,3 @@
 SHA512 (linux-libre-4.12-gnu.tar.xz) = d5586dba2e4deeb42ffe98c9305111da56e0741bb4508642d103367a0ef712c837e160366c3656d18f0d636fcd5b60c27593cb9216e10025d6abc74e6cdb05e4
 SHA512 (perf-man-4.12.tar.gz) = 4d3bbda1f520dba0007c351af46f45085fe4842074eb2e01aee736fd369df595f8f72ed6c1192715f1120bf3353279777f9dca1178fe93bffe5be2de700d409c
-SHA512 (patch-4.12-gnu-4.12.7-gnu.xz) = 6b7cffe7eacb689cf02bc58fbf4994f2105ad8735961c4d50321ccd3a3fc973f8ccd1246e3c5d01ac7b91b1d67e8e7c38a9433f032ed396691b2b7a12378538d
+SHA512 (patch-4.12-gnu-4.12.8-gnu.xz) = a2352b667dde19560fabf5253f68be6d7551ea1a842c60582633dd9e07669e260394806ccaf38dff68a2980abf73bd4a18ca4714d842b5b287e7e187f2af5211
diff --git a/freed-ora/current/f26/xsa229.patch b/freed-ora/current/f26/xsa229.patch
new file mode 100644
index 000000000..47e953843
--- /dev/null
+++ b/freed-ora/current/f26/xsa229.patch
@@ -0,0 +1,59 @@
+From 84882133e793299f685991e20a9631acfd0a5608 Mon Sep 17 00:00:00 2001
+From: Roger Pau Monne <roger.pau@citrix.com>
+Date: Tue, 18 Jul 2017 15:01:00 +0100
+Subject: xen: fix bio vec merging
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The current test for bio vec merging is not fully accurate and can be
+tricked into merging bios when certain grant combinations are used.
+The result of these malicious bio merges is a bio that extends past
+the memory page used by any of the originating bios.
+
+Take into account the following scenario, where a guest creates two
+grant references that point to the same mfn, ie: grant 1 -> mfn A,
+grant 2 -> mfn A.
+
+These references are then used in a PV block request, and mapped by
+the backend domain, thus obtaining two different pfns that point to
+the same mfn, pfn B -> mfn A, pfn C -> mfn A.
+
+If those grants happen to be used in two consecutive sectors of a disk
+IO operation becoming two different bios in the backend domain, the
+checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
+(they both point to the same mfn). However due to the bio merging,
+the backend domain will end up with a bio that expands past mfn A into
+mfn A + 1.
+
+Fix this by making sure the check in xen_biovec_phys_mergeable takes
+into account the offset and the length of the bio, this basically
+replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
+addresses). While there also remove the usage of
+__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
+of xen_biovec_phys_mergeable.
+
+Reported-by: "Jan H. Schönherr" <jschoenh@amazon.de>
+Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+---
+ drivers/xen/biomerge.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
+index 4da69dbf7dca..1bdd02a6d6ac 100644
+--- a/drivers/xen/biomerge.c
++++ b/drivers/xen/biomerge.c
+@@ -10,8 +10,7 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
+ 	unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page));
+ 	unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page));
+ 
+-	return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) &&
+-		((bfn1 == bfn2) || ((bfn1+1) == bfn2));
++	return bfn1 + PFN_DOWN(vec1->bv_offset + vec1->bv_len) == bfn2;
+ #else
+ 	/*
+ 	 * XXX: Add support for merging bio_vec when using different page
+-- 
+2.11.0 (Apple Git-81)
+