]> git.baikalelectronics.ru Git - kernel.git/commit
media: vivid: Fix wrong locking that causes race conditions on streaming stop
authorAlexander Popov <alex.popov@linux.com>
Sun, 3 Nov 2019 22:17:19 +0000 (23:17 +0100)
committerMauro Carvalho Chehab <mchehab@kernel.org>
Fri, 8 Nov 2019 06:38:59 +0000 (07:38 +0100)
commit8da7eb4c0fe83c03b41211aeae428e8892ef24da
tree19252bee195f8993f81b42c2623d2bfc69d8ef7a
parente98ba5dda4787d2cdffe814766cea16700426fdc
media: vivid: Fix wrong locking that causes race conditions on streaming stop

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>
drivers/media/platform/vivid/vivid-kthread-cap.c
drivers/media/platform/vivid/vivid-kthread-out.c
drivers/media/platform/vivid/vivid-sdr-cap.c