--- /dev/null
+From e6e8df07268c1f75dd9215536e2ce4587b70f977 Mon Sep 17 00:00:00 2001
+From: Kai Shen <shenkai8@huawei.com>
+Date: Thu, 7 Nov 2019 05:08:17 +0000
+Subject: cpufreq: Add NULL checks to show() and store() methods of cpufreq
+
+From: Kai Shen <shenkai8@huawei.com>
+
+commit e6e8df07268c1f75dd9215536e2ce4587b70f977 upstream.
+
+Add NULL checks to show() and store() in cpufreq.c to avoid attempts
+to invoke a NULL callback.
+
+Though some interfaces of cpufreq are set as read-only, users can
+still get write permission using chmod which can lead to a kernel
+crash, as follows:
+
+chmod +w /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
+
+This bug was found in linux 4.19.
+
+Signed-off-by: Kai Shen <shenkai8@huawei.com>
+Reported-by: Feilong Lin <linfeilong@huawei.com>
+Reviewed-by: Feilong Lin <linfeilong@huawei.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+[ rjw: Subject & changelog ]
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cpufreq.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -821,6 +821,9 @@ static ssize_t show(struct kobject *kobj
+ struct freq_attr *fattr = to_attr(attr);
+ ssize_t ret;
+
++ if (!fattr->show)
++ return -EIO;
++
+ down_read(&policy->rwsem);
+
+ if (fattr->show)
+@@ -1084,6 +1087,9 @@ static void cpufreq_policy_put_kobj(stru
+ up_write(&policy->rwsem);
+ kobject_put(kobj);
+
++ if (!fattr->store)
++ return -EIO;
++
+ /*
+ * We need to make sure that the underlying kobj is
+ * actually not referenced anymore by anybody before we
--- /dev/null
+From 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 Mon Sep 17 00:00:00 2001
+From: Alexander Popov <alex.popov@linux.com>
+Date: Sun, 3 Nov 2019 23:17:19 +0100
+Subject: media: vivid: Fix wrong locking that causes race conditions on streaming stop
+
+From: Alexander Popov <alex.popov@linux.com>
+
+commit 6dcd5d7a7a29c1e4b8016a06aed78cd650cd8c27 upstream.
+
+There is the same incorrect approach to locking implemented in
+vivid_stop_generating_vid_cap(), vivid_stop_generating_vid_out() and
+sdr_cap_stop_streaming().
+
+These functions are called during streaming stopping with vivid_dev.mutex
+locked. And they all do the same mistake while stopping their kthreads,
+which need to lock this mutex as well. See the example from
+vivid_stop_generating_vid_cap():
+ /* shutdown control thread */
+ vivid_grab_controls(dev, false);
+ mutex_unlock(&dev->mutex);
+ kthread_stop(dev->kthread_vid_cap);
+ dev->kthread_vid_cap = NULL;
+ mutex_lock(&dev->mutex);
+
+But when this mutex is unlocked, another vb2_fop_read() can lock it
+instead of vivid_thread_vid_cap() and manipulate the buffer queue.
+That causes a use-after-free access later.
+
+To fix those issues let's:
+ 1. avoid unlocking the mutex in vivid_stop_generating_vid_cap(),
+vivid_stop_generating_vid_out() and sdr_cap_stop_streaming();
+ 2. use mutex_trylock() with schedule_timeout_uninterruptible() in
+the loops of the vivid kthread handlers.
+
+Signed-off-by: Alexander Popov <alex.popov@linux.com>
+Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
+Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v3.18 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vivid/vivid-kthread-cap.c | 8 +++++---
+ drivers/media/platform/vivid/vivid-kthread-out.c | 8 +++++---
+ drivers/media/platform/vivid/vivid-sdr-cap.c | 8 +++++---
+ 3 files changed, 15 insertions(+), 9 deletions(-)
+
+--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
++++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
+@@ -763,7 +763,11 @@ static int vivid_thread_vid_cap(void *da
+ if (kthread_should_stop())
+ break;
+
+- mutex_lock(&dev->mutex);
++ if (!mutex_trylock(&dev->mutex)) {
++ schedule_timeout_uninterruptible(1);
++ continue;
++ }
++
+ cur_jiffies = jiffies;
+ if (dev->cap_seq_resync) {
+ dev->jiffies_vid_cap = cur_jiffies;
+@@ -916,8 +920,6 @@ void vivid_stop_generating_vid_cap(struc
+
+ /* shutdown control thread */
+ vivid_grab_controls(dev, false);
+- mutex_unlock(&dev->mutex);
+ kthread_stop(dev->kthread_vid_cap);
+ dev->kthread_vid_cap = NULL;
+- mutex_lock(&dev->mutex);
+ }
+--- a/drivers/media/platform/vivid/vivid-kthread-out.c
++++ b/drivers/media/platform/vivid/vivid-kthread-out.c
+@@ -147,7 +147,11 @@ static int vivid_thread_vid_out(void *da
+ if (kthread_should_stop())
+ break;
+
+- mutex_lock(&dev->mutex);
++ if (!mutex_trylock(&dev->mutex)) {
++ schedule_timeout_uninterruptible(1);
++ continue;
++ }
++
+ cur_jiffies = jiffies;
+ if (dev->out_seq_resync) {
+ dev->jiffies_vid_out = cur_jiffies;
+@@ -301,8 +305,6 @@ void vivid_stop_generating_vid_out(struc
+
+ /* shutdown control thread */
+ vivid_grab_controls(dev, false);
+- mutex_unlock(&dev->mutex);
+ kthread_stop(dev->kthread_vid_out);
+ dev->kthread_vid_out = NULL;
+- mutex_lock(&dev->mutex);
+ }
+--- a/drivers/media/platform/vivid/vivid-sdr-cap.c
++++ b/drivers/media/platform/vivid/vivid-sdr-cap.c
+@@ -151,7 +151,11 @@ static int vivid_thread_sdr_cap(void *da
+ if (kthread_should_stop())
+ break;
+
+- mutex_lock(&dev->mutex);
++ if (!mutex_trylock(&dev->mutex)) {
++ schedule_timeout_uninterruptible(1);
++ continue;
++ }
++
+ cur_jiffies = jiffies;
+ if (dev->sdr_cap_seq_resync) {
+ dev->jiffies_sdr_cap = cur_jiffies;
+@@ -311,10 +315,8 @@ static void sdr_cap_stop_streaming(struc
+ }
+
+ /* shutdown control thread */
+- mutex_unlock(&dev->mutex);
+ kthread_stop(dev->kthread_sdr_cap);
+ dev->kthread_sdr_cap = NULL;
+- mutex_lock(&dev->mutex);
+ }
+
+ const struct vb2_ops vivid_sdr_cap_qops = {
--- /dev/null
+From b4add02d2236fd5f568db141cfd8eb4290972eb3 Mon Sep 17 00:00:00 2001
+From: Vandana BN <bnvandana@gmail.com>
+Date: Mon, 9 Sep 2019 06:43:31 -0300
+Subject: media: vivid: Set vid_cap_streaming and vid_out_streaming to true
+
+From: Vandana BN <bnvandana@gmail.com>
+
+commit b4add02d2236fd5f568db141cfd8eb4290972eb3 upstream.
+
+When vbi stream is started, followed by video streaming,
+the vid_cap_streaming and vid_out_streaming were not being set to true,
+which would cause the video stream to stop when vbi stream is stopped.
+This patch allows to set vid_cap_streaming and vid_out_streaming to true.
+According to Hans Verkuil it appears that these 'if (dev->kthread_vid_cap)'
+checks are a left-over from the original vivid development and should never
+have been there.
+
+Signed-off-by: Vandana BN <bnvandana@gmail.com>
+Cc: <stable@vger.kernel.org> # for v3.18 and up
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vivid/vivid-vid-cap.c | 3 ---
+ drivers/media/platform/vivid/vivid-vid-out.c | 3 ---
+ 2 files changed, 6 deletions(-)
+
+--- a/drivers/media/platform/vivid/vivid-vid-cap.c
++++ b/drivers/media/platform/vivid/vivid-vid-cap.c
+@@ -253,9 +253,6 @@ static int vid_cap_start_streaming(struc
+ if (vb2_is_streaming(&dev->vb_vid_out_q))
+ dev->can_loop_video = vivid_vid_can_loop(dev);
+
+- if (dev->kthread_vid_cap)
+- return 0;
+-
+ dev->vid_cap_seq_count = 0;
+ dprintk(dev, 1, "%s\n", __func__);
+ for (i = 0; i < VIDEO_MAX_FRAME; i++)
+--- a/drivers/media/platform/vivid/vivid-vid-out.c
++++ b/drivers/media/platform/vivid/vivid-vid-out.c
+@@ -173,9 +173,6 @@ static int vid_out_start_streaming(struc
+ if (vb2_is_streaming(&dev->vb_vid_cap_q))
+ dev->can_loop_video = vivid_vid_can_loop(dev);
+
+- if (dev->kthread_vid_out)
+- return 0;
+-
+ dev->vid_out_seq_count = 0;
+ dprintk(dev, 1, "%s\n", __func__);
+ if (dev->start_streaming_error) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
