linux-stable.git/drivers/media, branch v3.16.82

media: exynos4-is: Fix recursive locking in isp_video_release()

2020-02-11T20:03:26+00:00

commit 704c6c80fb471d1bb0ef0d61a94617d1d55743cd upstream.

>From isp_video_release(), &isp->video_lock is held and subsequent
vb2_fop_release() tries to lock vdev->lock which is same with the
previous one. Replace vb2_fop_release() with _vb2_fop_release() to
fix the recursive locking.

Fixes: 1380f5754cb0 ("[media] videobuf2: Add missing lock held on vb2_fop_release")
Signed-off-by: Seung-Woo Kim 
Reviewed-by: Sylwester Nawrocki 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

media: radio: wl1273: fix interrupt masking on release

2020-02-11T20:03:26+00:00

commit 1091eb830627625dcf79958d99353c2391f41708 upstream.

If a process is interrupted while accessing the radio device and the
core lock is contended, release() could return early and fail to update
the interrupt mask.

Note that the return value of the v4l2 release file operation is
ignored.

Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver")
Cc: Matti Aaltonen 
Signed-off-by: Johan Hovold 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

media: usbvision: Fix races among open, close, and disconnect

2020-02-11T20:03:17+00:00

commit 9e08117c9d4efc1e1bc6fce83dab856d9fd284b6 upstream.

Visual inspection of the usbvision driver shows that it suffers from
three races between its open, close, and disconnect handlers.  In
particular, the driver is careful to update its usbvision->user and
usbvision->remove_pending flags while holding the private mutex, but:

	usbvision_v4l2_close() and usbvision_radio_close() don't hold
	the mutex while they check the value of
	usbvision->remove_pending;

	usbvision_disconnect() doesn't hold the mutex while checking
	the value of usbvision->user; and

	also, usbvision_v4l2_open() and usbvision_radio_open() don't
	check whether the device has been unplugged before allowing
	the user to open the device files.

Each of these can potentially lead to usbvision_release() being called
twice and use-after-free errors.

This patch fixes the races by reading the flags while the mutex is
still held and checking for pending removes before allowing an open to
succeed.

Signed-off-by: Alan Stern 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16:
 - Add unlock label in usbvision_v4l2_open()
 - Adjust context]
Signed-off-by: Ben Hutchings

media: usbvision: Fix invalid accesses after device disconnect

2020-02-11T20:03:17+00:00

commit c7a191464078262bf799136317c95824e26a222b upstream.

The syzbot fuzzer found two invalid-access bugs in the usbvision
driver.  These bugs occur when userspace keeps the device file open
after the device has been disconnected and usbvision_disconnect() has
set usbvision->dev to NULL:

	When the device file is closed, usbvision_radio_close() tries
	to issue a usb_set_interface() call, passing the NULL pointer
	as its first argument.

	If userspace performs a querycap ioctl call, vidioc_querycap()
	calls usb_make_path() with the same NULL pointer.

This patch fixes the problems by making the appropriate tests
beforehand.  Note that vidioc_querycap() is protected by
usbvision->v4l2_lock, acquired in a higher layer of the V4L2
subsystem.

Reported-and-tested-by: syzbot+7fa38a608b1075dfd634@syzkaller.appspotmail.com

Signed-off-by: Alan Stern 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

usbvision: fix locking error

2020-02-11T20:03:16+00:00

commit 5ce625a42d6206d5a18222c6475f6b866ef68569 upstream.

When remove_pending is non-zero, v4l2_lock is never unlocked.

Signed-off-by: Insu Yun 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

usbvision: fix locking error

2020-02-11T20:03:16+00:00

commit e2c84ccb0fbe5e524d15bb09c042a6ca634adaed upstream.

If remove_pending is non-zero, then the v4l2_lock is never unlocked.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

usbvision-video: two use after frees

2020-02-11T20:03:16+00:00

commit 470a9147899500eb4898f77816520c4b4aa1a698 upstream.

The lock has been freed in usbvision_release() so there is no need to
call mutex_unlock() here.

Signed-off-by: Dan Carpenter 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Ben Hutchings

usbvision: remove power_on_at_open and timed power off

2020-02-11T20:03:15+00:00

commit 62e259493d779b0e2c1a675ab733136511310821 upstream.

This causes lots of problems and is *very* slow as well.

One of the main problems is that this prohibits the use of the control
framework since subdevs will be unloaded on power off which is not allowed
as long as they are used by a usb device.

Apparently the reason for doing this is to turn off a noisy tuner. My hardware
has no problem with that, and I wonder whether the hardware with that noisy
tuner wasn't just functioning improperly as I have never heard of noisy tuners.

Contact me if you have one of those devices and I can take a look whether the
tuner can't be powered off if necessary by letting the tuner subdevice go
into standby mode. Unloading the tuner module is just evil and is not the
right approach.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16 as dependency of locking fixes. Our version of
 usbvision_init_power_off_timer() was slightly different.]
Signed-off-by: Ben Hutchings

media: ov6650: Fix stored frame format not in sync with hardware

2020-02-11T20:03:13+00:00

commit 3143b459de4cdcce67b36827476c966e93c1cf01 upstream.

The driver stores frame format settings supposed to be in line with
hardware state in a device private structure.  Since the driver initial
submission, those settings are updated before they are actually applied
on hardware.  If an error occurs on device update, the stored settings
my not reflect hardware state anymore and consecutive calls to
.get_fmt() may return incorrect information.  That in turn may affect
ability of a bridge device to use correct DMA transfer settings if such
incorrect informmation on active frame format returned by .get_fmt() is
used.

Assuming a failed device update means its state hasn't changed, update
frame format related settings stored in the device private structure
only after they are successfully applied so the stored values always
reflect hardware state as closely as possible.

Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor")
Signed-off-by: Janusz Krzysztofik 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

media: ov6650: Fix incorrect use of JPEG colorspace

2020-02-11T20:03:13+00:00

commit 12500731895ef09afc5b66b86b76c0884fb9c7bf upstream.

Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG
for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8.  According
to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies
exclusively to V4L2_PIX_FMT_JPEG.  Since the sensor does not support
JPEG format, fix it to always select V4L2_COLORSPACE_SRGB.

Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor")
Signed-off-by: Janusz Krzysztofik 
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings