linux-stable.git/drivers/media, branch v5.4.11 Linux kernel stable tree media: usb: fix memory leak in af9005_identify_state 2020-01-09T09:20:05+00:00 Navid Emamdoost navid.emamdoost@gmail.com 2019-10-09T15:01:47+00:00 3dba6e50d09ee8c05d5ba68bd69624ac1ea0c814 commit 2289adbfa559050d2a38bcd9caac1c18b800e928 upstream. In af9005_identify_state when returning -EIO the allocated buffer should be released. Replace the "return -EIO" with assignment into ret and move deb_info() under a check. Fixes: af4e067e1dcf ("V4L/DVB (5625): Add support for the AF9005 demodulator from Afatech") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> 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> 
commit 2289adbfa559050d2a38bcd9caac1c18b800e928 upstream.

In af9005_identify_state when returning -EIO the allocated buffer should
be released. Replace the "return -EIO" with assignment into ret and move
deb_info() under a check.

Fixes: af4e067e1dcf ("V4L/DVB (5625): Add support for the AF9005 demodulator from Afatech")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
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>
media: flexcop-usb: ensure -EIO is returned on error condition 2020-01-09T09:20:04+00:00 Colin Ian King colin.king@canonical.com 2019-10-25T13:33:39+00:00 6851d4004b6f770dd9e71b4da61a02d14cbacedb commit 74a96b51a36de4d86660fbc56b05d86668162d6b upstream. An earlier commit hard coded a return 0 to function flexcop_usb_i2c_req even though the an -EIO was intended to be returned in the case where ret != buflen. Fix this by replacing the return 0 with the return of ret to return the error return code. Addresses-Coverity: ("Unused value") Fixes: b430eaba0be5 ("[media] flexcop-usb: don't use stack for DMA") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 74a96b51a36de4d86660fbc56b05d86668162d6b upstream.

An earlier commit hard coded a return 0 to function flexcop_usb_i2c_req
even though the an -EIO was intended to be returned in the case where
ret != buflen.  Fix this by replacing the return 0 with the return of
ret to return the error return code.

Addresses-Coverity: ("Unused value")

Fixes: b430eaba0be5 ("[media] flexcop-usb: don't use stack for DMA")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: cec: check 'transmit_in_progress', not 'transmitting' 2020-01-09T09:19:56+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-12-11T11:47:57+00:00 80d9e63714a43a162ce79abe33dd18a2111f3c4e commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream. Currently wait_event_interruptible_timeout is called in cec_thread_func() when adap->transmitting is set. But if the adapter is unconfigured while transmitting, then adap->transmitting is set to NULL. But the hardware is still actually transmitting the message, and that's indicated by adap->transmit_in_progress and we should wait until that is finished or times out before transmitting new messages. As the original commit says: adap->transmitting is the userspace view, adap->transmit_in_progress reflects the hardware state. However, if adap->transmitting is NULL and adap->transmit_in_progress is true, then wait_event_interruptible is called (no timeout), which can get stuck indefinitely if the CEC driver is flaky and never marks the transmit-in-progress as 'done'. So test against transmit_in_progress when deciding whether to use the timeout variant or not, instead of testing against adap->transmitting. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits") Cc: <stable@vger.kernel.org> # for v4.19 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream.

Currently wait_event_interruptible_timeout is called in cec_thread_func()
when adap->transmitting is set. But if the adapter is unconfigured
while transmitting, then adap->transmitting is set to NULL. But the
hardware is still actually transmitting the message, and that's
indicated by adap->transmit_in_progress and we should wait until that
is finished or times out before transmitting new messages.

As the original commit says: adap->transmitting is the userspace view,
adap->transmit_in_progress reflects the hardware state.

However, if adap->transmitting is NULL and adap->transmit_in_progress
is true, then wait_event_interruptible is called (no timeout), which
can get stuck indefinitely if the CEC driver is flaky and never marks
the transmit-in-progress as 'done'.

So test against transmit_in_progress when deciding whether to use
the timeout variant or not, instead of testing against adap->transmitting.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits")
Cc: <stable@vger.kernel.org>      # for v4.19 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: cec: avoid decrementing transmit_queue_sz if it is 0 2020-01-09T09:19:56+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-12-07T22:48:09+00:00 9a7130220ab48b251987c3ec5843116285e67b22 commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream. WARN if transmit_queue_sz is 0 but do not decrement it. The CEC adapter will become unresponsive if it goes below 0 since then it thinks there are 4 billion messages in the queue. Obviously this should not happen, but a driver bug could cause this. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.12 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream.

WARN if transmit_queue_sz is 0 but do not decrement it.
The CEC adapter will become unresponsive if it goes below
0 since then it thinks there are 4 billion messages in the
queue.

Obviously this should not happen, but a driver bug could
cause this.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: <stable@vger.kernel.org>      # for v4.12 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: cec: CEC 2.0-only bcast messages were ignored 2020-01-09T09:19:56+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-12-04T07:52:08+00:00 e572db9a4dfe78bfa4a972832609de40907f21cb commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream. Some messages are allowed to be a broadcast message in CEC 2.0 only, and should be ignored by CEC 1.4 devices. Unfortunately, the check was wrong, causing such messages to be marked as invalid under CEC 2.0. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream.

Some messages are allowed to be a broadcast message in CEC 2.0
only, and should be ignored by CEC 1.4 devices.

Unfortunately, the check was wrong, causing such messages to be
marked as invalid under CEC 2.0.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: <stable@vger.kernel.org>      # for v4.10 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: pulse8-cec: fix lost cec_transmit_attempt_done() call 2020-01-09T09:19:56+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-12-07T22:43:23+00:00 f868e597a3d9e66c61cb6a23f64dc9ec8361113c commit e5a52a1d15c79bb48a430fb263852263ec1d3f11 upstream. The periodic PING command could interfere with the result of a CEC transmit, causing a lost cec_transmit_attempt_done() call. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v4.10 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e5a52a1d15c79bb48a430fb263852263ec1d3f11 upstream.

The periodic PING command could interfere with the result of
a CEC transmit, causing a lost cec_transmit_attempt_done()
call.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: <stable@vger.kernel.org>      # for v4.10 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: vim2m: media_device_cleanup was called too early 2019-12-31T15:45:17+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-11-09T13:03:08+00:00 129c37017392a8bcd7e5005a9d185f7bc103cb59 [ Upstream commit 9f22e88a4bba270d3427684cee84dfbf67489e86 ] Running the contrib/test/test-media script in v4l-utils with the vim2m argument will cause this kernel warning: [ 554.430157] ------------[ cut here ]------------ [ 554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380 [ 554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid] [ 554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1 [ 554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380 [ 554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48 [ 554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282 [ 554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f [ 554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4 [ 554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681 [ 554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000 [ 554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8 [ 554.479622] FS: 00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000 [ 554.482673] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0 [ 554.487811] Call Trace: [ 554.488860] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.490818] ? do_exit+0x946/0x2980 [ 554.492269] ? mutex_lock_io_nested+0x1250/0x1250 [ 554.494128] ? __lock_acquire+0xe90/0x3c30 [ 554.495774] ? fsnotify_first_mark+0x120/0x120 [ 554.497487] ? vim2m_device_release+0x50/0x50 [vim2m] [ 554.499469] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.501493] v4l2_release+0x1b8/0x390 [videodev] [ 554.503430] __fput+0x256/0x790 [ 554.504711] task_work_run+0x109/0x190 [ 554.506145] do_exit+0x95e/0x2980 [ 554.507421] ? vfs_lock_file+0x21/0xf0 [ 554.509013] ? find_held_lock+0x33/0x1c0 [ 554.510382] ? __close_fd+0xee/0x190 [ 554.511862] ? release_task.part.21+0x1310/0x1310 [ 554.513701] ? lock_downgrade+0x6d0/0x6d0 [ 554.515299] do_group_exit+0xeb/0x2d0 [ 554.516862] __x64_sys_exit_group+0x35/0x40 [ 554.518610] do_syscall_64+0x90/0x450 [ 554.520142] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 554.522289] RIP: 0033:0x7fac6348ecf6 [ 554.523876] Code: Bad RIP value. [ 554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6 [ 554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760 [ 554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000 [ 554.540634] irq event stamp: 21731 [ 554.541618] hardirqs last enabled at (21731): [<ffffffffb75b3cd4>] _raw_spin_unlock_irq+0x24/0x30 [ 554.544145] hardirqs last disabled at (21730): [<ffffffffb75b3ada>] _raw_spin_lock_irq+0xa/0x40 [ 554.547027] softirqs last enabled at (20148): [<ffffffffb780064d>] __do_softirq+0x64d/0x906 [ 554.550385] softirqs last disabled at (19857): [<ffffffffb5926bd5>] irq_exit+0x175/0x1a0 [ 554.553668] ---[ end trace a389c80c2ca84244 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the video_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9f22e88a4bba270d3427684cee84dfbf67489e86 ]

Running the contrib/test/test-media script in v4l-utils with the vim2m argument
will cause this kernel warning:

[  554.430157] ------------[ cut here ]------------
[  554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[  554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380
[  554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid]
[  554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1
[  554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[  554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380
[  554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48
[  554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282
[  554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f
[  554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4
[  554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681
[  554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000
[  554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8
[  554.479622] FS:  00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000
[  554.482673] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0
[  554.487811] Call Trace:
[  554.488860]  ? v4l2_release+0x1b8/0x390 [videodev]
[  554.490818]  ? do_exit+0x946/0x2980
[  554.492269]  ? mutex_lock_io_nested+0x1250/0x1250
[  554.494128]  ? __lock_acquire+0xe90/0x3c30
[  554.495774]  ? fsnotify_first_mark+0x120/0x120
[  554.497487]  ? vim2m_device_release+0x50/0x50 [vim2m]
[  554.499469]  ? v4l2_release+0x1b8/0x390 [videodev]
[  554.501493]  v4l2_release+0x1b8/0x390 [videodev]
[  554.503430]  __fput+0x256/0x790
[  554.504711]  task_work_run+0x109/0x190
[  554.506145]  do_exit+0x95e/0x2980
[  554.507421]  ? vfs_lock_file+0x21/0xf0
[  554.509013]  ? find_held_lock+0x33/0x1c0
[  554.510382]  ? __close_fd+0xee/0x190
[  554.511862]  ? release_task.part.21+0x1310/0x1310
[  554.513701]  ? lock_downgrade+0x6d0/0x6d0
[  554.515299]  do_group_exit+0xeb/0x2d0
[  554.516862]  __x64_sys_exit_group+0x35/0x40
[  554.518610]  do_syscall_64+0x90/0x450
[  554.520142]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  554.522289] RIP: 0033:0x7fac6348ecf6
[  554.523876] Code: Bad RIP value.
[  554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[  554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6
[  554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[  554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[  554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760
[  554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000
[  554.540634] irq event stamp: 21731
[  554.541618] hardirqs last  enabled at (21731): [<ffffffffb75b3cd4>] _raw_spin_unlock_irq+0x24/0x30
[  554.544145] hardirqs last disabled at (21730): [<ffffffffb75b3ada>] _raw_spin_lock_irq+0xa/0x40
[  554.547027] softirqs last  enabled at (20148): [<ffffffffb780064d>] __do_softirq+0x64d/0x906
[  554.550385] softirqs last disabled at (19857): [<ffffffffb5926bd5>] irq_exit+0x175/0x1a0
[  554.553668] ---[ end trace a389c80c2ca84244 ]---

This is caused by media_device_cleanup() which destroys
v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock
that mutex after media_device_cleanup() is called.

By moving media_device_cleanup() to the video_device's release function it is
guaranteed that the mutex is valid whenever v4l2_release is called.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: vicodec: media_device_cleanup was called too early 2019-12-31T15:45:16+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-11-09T14:06:18+00:00 f5f842069a911605ede770ef70118b5baaf97892 [ Upstream commit 693c5f144aeb9636ae161a3c61a838c50b2ae41c ] Running the contrib/test/test-media script in v4l-utils with the vicodec argument will cause this kernel warning: [ 372.298824] ------------[ cut here ]------------ [ 372.298848] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 372.298896] WARNING: CPU: 11 PID: 2220 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 372.298907] Modules linked in: vicodec v4l2_mem2mem vivid rc_cec v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [last unloaded: vimc] [ 372.298961] CPU: 11 PID: 2220 Comm: sleep Not tainted 5.4.0-rc1-test-no #150 [ 372.298970] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 372.298983] RIP: 0010:__mutex_lock+0x919/0xc10 [ 372.298995] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 372.299004] RSP: 0018:ffff8881b400fb80 EFLAGS: 00010286 [ 372.299014] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 372.299022] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed1036801f62 [ 372.299030] RBP: ffff8881b400fcf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 372.299038] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff88814761dc80 [ 372.299046] R13: 0000000000000000 R14: ffff88814761cbf0 R15: ffff88814761d030 [ 372.299055] FS: 0000000000000000(0000) GS:ffff8881b68c0000(0000) knlGS:0000000000000000 [ 372.299063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 372.299071] CR2: 00007f606d78aa20 CR3: 0000000003013002 CR4: 00000000001606e0 [ 372.299153] Call Trace: [ 372.299176] ? __kasan_slab_free+0x12f/0x180 [ 372.299187] ? kmem_cache_free+0x9b/0x250 [ 372.299200] ? do_exit+0xcdf/0x1200 [ 372.299210] ? do_group_exit+0x85/0x130 [ 372.299220] ? __x64_sys_exit_group+0x23/0x30 [ 372.299231] ? do_syscall_64+0x5e/0x1c0 [ 372.299241] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299295] ? v4l2_release+0xed/0x190 [videodev] [ 372.299309] ? mutex_lock_io_nested+0xb80/0xb80 [ 372.299323] ? find_held_lock+0x85/0xa0 [ 372.299335] ? fsnotify+0x5b0/0x600 [ 372.299351] ? locks_remove_file+0x78/0x2b0 [ 372.299363] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 372.299383] ? vidioc_querycap+0x50/0x50 [vicodec] [ 372.299426] ? v4l2_release+0xed/0x190 [videodev] [ 372.299467] v4l2_release+0xed/0x190 [videodev] [ 372.299484] __fput+0x15a/0x390 [ 372.299499] task_work_run+0xb2/0xe0 [ 372.299512] do_exit+0x4d0/0x1200 [ 372.299528] ? do_user_addr_fault+0x367/0x610 [ 372.299538] ? release_task+0x990/0x990 [ 372.299552] ? rwsem_spin_on_owner+0x170/0x170 [ 372.299567] ? vmacache_find+0xb2/0x100 [ 372.299580] do_group_exit+0x85/0x130 [ 372.299592] __x64_sys_exit_group+0x23/0x30 [ 372.299602] do_syscall_64+0x5e/0x1c0 [ 372.299614] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299624] RIP: 0033:0x7f606d74a9d6 [ 372.299640] Code: Bad RIP value. [ 372.299648] RSP: 002b:00007fff65364468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 372.299658] RAX: ffffffffffffffda RBX: 00007f606d83b760 RCX: 00007f606d74a9d6 [ 372.299666] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 372.299673] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 372.299681] R10: 00007fff65364334 R11: 0000000000000246 R12: 00007f606d83b760 [ 372.299689] R13: 0000000000000002 R14: 00007f606d844428 R15: 0000000000000000 [ 372.299704] ---[ end trace add7d62ca4bc65e3 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 693c5f144aeb9636ae161a3c61a838c50b2ae41c ]

Running the contrib/test/test-media script in v4l-utils with the vicodec argument
will cause this kernel warning:

[  372.298824] ------------[ cut here ]------------
[  372.298848] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[  372.298896] WARNING: CPU: 11 PID: 2220 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10
[  372.298907] Modules linked in: vicodec v4l2_mem2mem vivid rc_cec v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [last unloaded: vimc]
[  372.298961] CPU: 11 PID: 2220 Comm: sleep Not tainted 5.4.0-rc1-test-no #150
[  372.298970] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019
[  372.298983] RIP: 0010:__mutex_lock+0x919/0xc10
[  372.298995] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7
[  372.299004] RSP: 0018:ffff8881b400fb80 EFLAGS: 00010286
[  372.299014] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  372.299022] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed1036801f62
[  372.299030] RBP: ffff8881b400fcf0 R08: ffffffff81217c91 R09: fffffbfff061c271
[  372.299038] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff88814761dc80
[  372.299046] R13: 0000000000000000 R14: ffff88814761cbf0 R15: ffff88814761d030
[  372.299055] FS:  0000000000000000(0000) GS:ffff8881b68c0000(0000) knlGS:0000000000000000
[  372.299063] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  372.299071] CR2: 00007f606d78aa20 CR3: 0000000003013002 CR4: 00000000001606e0
[  372.299153] Call Trace:
[  372.299176]  ? __kasan_slab_free+0x12f/0x180
[  372.299187]  ? kmem_cache_free+0x9b/0x250
[  372.299200]  ? do_exit+0xcdf/0x1200
[  372.299210]  ? do_group_exit+0x85/0x130
[  372.299220]  ? __x64_sys_exit_group+0x23/0x30
[  372.299231]  ? do_syscall_64+0x5e/0x1c0
[  372.299241]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  372.299295]  ? v4l2_release+0xed/0x190 [videodev]
[  372.299309]  ? mutex_lock_io_nested+0xb80/0xb80
[  372.299323]  ? find_held_lock+0x85/0xa0
[  372.299335]  ? fsnotify+0x5b0/0x600
[  372.299351]  ? locks_remove_file+0x78/0x2b0
[  372.299363]  ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170
[  372.299383]  ? vidioc_querycap+0x50/0x50 [vicodec]
[  372.299426]  ? v4l2_release+0xed/0x190 [videodev]
[  372.299467]  v4l2_release+0xed/0x190 [videodev]
[  372.299484]  __fput+0x15a/0x390
[  372.299499]  task_work_run+0xb2/0xe0
[  372.299512]  do_exit+0x4d0/0x1200
[  372.299528]  ? do_user_addr_fault+0x367/0x610
[  372.299538]  ? release_task+0x990/0x990
[  372.299552]  ? rwsem_spin_on_owner+0x170/0x170
[  372.299567]  ? vmacache_find+0xb2/0x100
[  372.299580]  do_group_exit+0x85/0x130
[  372.299592]  __x64_sys_exit_group+0x23/0x30
[  372.299602]  do_syscall_64+0x5e/0x1c0
[  372.299614]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  372.299624] RIP: 0033:0x7f606d74a9d6
[  372.299640] Code: Bad RIP value.
[  372.299648] RSP: 002b:00007fff65364468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[  372.299658] RAX: ffffffffffffffda RBX: 00007f606d83b760 RCX: 00007f606d74a9d6
[  372.299666] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[  372.299673] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
[  372.299681] R10: 00007fff65364334 R11: 0000000000000246 R12: 00007f606d83b760
[  372.299689] R13: 0000000000000002 R14: 00007f606d844428 R15: 0000000000000000
[  372.299704] ---[ end trace add7d62ca4bc65e3 ]---

This is caused by media_device_cleanup() which destroys
v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock
that mutex after media_device_cleanup() is called.

By moving media_device_cleanup() to the v4l2_device's release function it is
guaranteed that the mutex is valid whenever v4l2_release is called.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: v4l2-ctrl: Lock main_hdl on operations of requests_queued. 2019-12-31T15:45:14+00:00 Pi-Hsun Shih pihsun@chromium.org 2019-11-10T06:29:10+00:00 aa32eb1a1043400c112586953d5e6ec94ea659cd [ Upstream commit df4a3e7f88e3b0d7ae46d70b9ff8e3c0ea730785 ] There's a race condition between the list_del_init in the v4l2_ctrl_request_complete, and the list_add_tail in the v4l2_ctrl_request_queue, since they can be called in different thread and the requests_queued list is not protected by a lock. This can lead to that the v4l2_ctrl_handler is still in the requests_queued list while the request_is_queued is already set to false, which would cause use-after-free if the v4l2_ctrl_handler is later released. Fix this by locking the ->lock of main_hdl (which is the owner of the requests_queued list) when doing list operations on the ->requests_queued list. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit df4a3e7f88e3b0d7ae46d70b9ff8e3c0ea730785 ]

There's a race condition between the list_del_init in the
v4l2_ctrl_request_complete, and the list_add_tail in the
v4l2_ctrl_request_queue, since they can be called in different thread
and the requests_queued list is not protected by a lock. This can lead
to that the v4l2_ctrl_handler is still in the requests_queued list while
the request_is_queued is already set to false, which would cause
use-after-free if the v4l2_ctrl_handler is later released.

Fix this by locking the ->lock of main_hdl (which is the owner of the
requests_queued list) when doing list operations on the
->requests_queued list.

Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: si470x-i2c: add missed operations in remove 2019-12-31T15:45:13+00:00 Chuhong Yuan hslester96@gmail.com 2019-11-10T06:28:15+00:00 c1d3b5cdb5bf1b6151fef96ef487f0e170a64247 [ Upstream commit 2df200ab234a86836a8879a05a8007d6b884eb14 ] The driver misses calling v4l2_ctrl_handler_free and v4l2_device_unregister in remove like what is done in probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2df200ab234a86836a8879a05a8007d6b884eb14 ]

The driver misses calling v4l2_ctrl_handler_free and
v4l2_device_unregister in remove like what is done in probe failure.
Add the calls to fix it.

Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>