<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/media/usb, branch v4.19.39</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.39</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.39'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-04-20T07:16:01+00:00</updated>
<entry>
<title>media: au0828: cannot kfree dev before usb disconnect</title>
<updated>2019-04-20T07:16:01+00:00</updated>
<author>
<name>Brad Love</name>
<email>brad@nextdimension.cc</email>
</author>
<published>2018-09-06T21:07:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6496b9636f747361a47feb35f953b7f9236954f9'/>
<id>urn:sha1:6496b9636f747361a47feb35f953b7f9236954f9</id>
<content type='text'>
[ Upstream commit 4add7104919f9e94e0db03e234caeadbfcc02ea9 ]

If au0828_analog_register fails, the dev is kfree'd and then flow
jumps to done, which can call au0828_usb_disconnect. Since all USB
error codes are negative, au0828_usb_disconnect will be called. The
problem is au0828_usb_disconnect uses dev, if dev is NULL then there
is immediate oops encountered.

[    7.454307] au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
[    7.454323] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[    7.454421] PGD 0 P4D 0
[    7.454457] Oops: 0002 [#1] SMP PTI
[    7.454500] CPU: 1 PID: 262 Comm: systemd-udevd Tainted: P           O      4.18.3 #1
[    7.454584] Hardware name: Google Panther/Panther, BIOS MattDevo 04/27/2015
[    7.454670] RIP: 0010:_raw_spin_lock_irqsave+0x2c/0x50
[    7.454725] Code: 44 00 00 55 48 89 e5 41 54 53 48 89 fb 9c 58 0f 1f 44 00 00 49 89 c4 fa 66 0f 1f 44 00 00 e8 db 23 1b ff 31 c0 ba 01 00 00 00 &lt;f0&gt; 0f b1 13 85 c0 75 08 4c 89 e0 5b 41 5c 5d c3 89 c6 48 89 df e8
[    7.455004] RSP: 0018:ffff9130f53ef988 EFLAGS: 00010046
[    7.455063] RAX: 0000000000000000 RBX: 0000000000000050 RCX: 0000000000000000
[    7.455139] RDX: 0000000000000001 RSI: 0000000000000003 RDI: 0000000000000050
[    7.455216] RBP: ffff9130f53ef998 R08: 0000000000000018 R09: 0000000000000090
[    7.455292] R10: ffffed4cc53cb000 R11: ffffed4cc53cb108 R12: 0000000000000082
[    7.455369] R13: ffff9130cf2c6188 R14: 0000000000000000 R15: 0000000000000018
[    7.455447] FS:  00007f2ff8514cc0(0000) GS:ffff9130fcb00000(0000) knlGS:0000000000000000
[    7.455535] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    7.455597] CR2: 0000000000000050 CR3: 00000001753f0002 CR4: 00000000000606a0
[    7.455675] Call Trace:
[    7.455713]  __wake_up_common_lock+0x65/0xc0
[    7.455764]  __wake_up+0x13/0x20
[    7.455808]  ir_lirc_unregister+0x57/0xe0 [rc_core]
[    7.455865]  rc_unregister_device+0xa0/0xc0 [rc_core]
[    7.455935]  au0828_rc_unregister+0x25/0x40 [au0828]
[    7.455999]  au0828_usb_disconnect+0x33/0x80 [au0828]
[    7.456064]  au0828_usb_probe.cold.16+0x8d/0x2aa [au0828]
[    7.456130]  usb_probe_interface+0xf1/0x300
[    7.456184]  driver_probe_device+0x2e3/0x460
[    7.456235]  __driver_attach+0xe4/0x110
[    7.456282]  ? driver_probe_device+0x460/0x460
[    7.456335]  bus_for_each_dev+0x74/0xb0
[    7.456385]  ? kmem_cache_alloc_trace+0x15d/0x1d0
[    7.456441]  driver_attach+0x1e/0x20
[    7.456485]  bus_add_driver+0x159/0x230
[    7.456532]  driver_register+0x70/0xc0
[    7.456578]  usb_register_driver+0x7f/0x140
[    7.456626]  ? 0xffffffffc0474000
[    7.456674]  au0828_init+0xbc/0x1000 [au0828]
[    7.456725]  do_one_initcall+0x4a/0x1c9
[    7.456771]  ? _cond_resched+0x19/0x30
[    7.456817]  ? kmem_cache_alloc_trace+0x15d/0x1d0
[    7.456873]  do_init_module+0x60/0x210
[    7.456918]  load_module+0x221b/0x2710
[    7.456966]  ? vfs_read+0xf5/0x120
[    7.457010]  __do_sys_finit_module+0xbd/0x120
[    7.457061]  ? __do_sys_finit_module+0xbd/0x120
[    7.457115]  __x64_sys_finit_module+0x1a/0x20
[    7.457166]  do_syscall_64+0x5b/0x110
[    7.457210]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Signed-off-by: Brad Love &lt;brad@nextdimension.cc&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: v4l2-ctrls.c/uvc: zero v4l2_event</title>
<updated>2019-03-27T05:14:41+00:00</updated>
<author>
<name>Hans Verkuil</name>
<email>hverkuil@xs4all.nl</email>
</author>
<published>2018-12-18T13:37:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6bef442eea18ce95afec1bad4927cb9d68c1505e'/>
<id>urn:sha1:6bef442eea18ce95afec1bad4927cb9d68c1505e</id>
<content type='text'>
commit f45f3f753b0a3d739acda8e311b4f744d82dc52a upstream.

Control events can leak kernel memory since they do not fully zero the
event. The same code is present in both v4l2-ctrls.c and uvc_ctrl.c, so
fix both.

It appears that all other event code is properly zeroing the structure,
it's these two places.

Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Reported-by: syzbot+4f021cf3697781dbd9fb@syzkaller.appspotmail.com
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: uvcvideo: Avoid NULL pointer dereference at the end of streaming</title>
<updated>2019-03-23T19:10:12+00:00</updated>
<author>
<name>Sakari Ailus</name>
<email>sakari.ailus@linux.intel.com</email>
</author>
<published>2019-01-30T10:09:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29e8c9ae99c78b14b7b1bc5bd80ee1163bcc0777'/>
<id>urn:sha1:29e8c9ae99c78b14b7b1bc5bd80ee1163bcc0777</id>
<content type='text'>
commit 9dd0627d8d62a7ddb001a75f63942d92b5336561 upstream.

The UVC video driver converts the timestamp from hardware specific unit
to one known by the kernel at the time when the buffer is dequeued. This
is fine in general, but the streamoff operation consists of the
following steps (among other things):

1. uvc_video_clock_cleanup --- the hardware clock sample array is
   released and the pointer to the array is set to NULL,

2. buffers in active state are returned to the user and

3. buf_finish callback is called on buffers that are prepared.
   buf_finish includes calling uvc_video_clock_update that accesses the
   hardware clock sample array.

The above is serialised by a queue specific mutex. Address the problem
by skipping the clock conversion if the hardware clock sample array is
already released.

Fixes: 9c0863b1cc48 ("[media] vb2: call buf_finish from __queue_cancel")

Reported-by: Chiranjeevi Rapolu &lt;chiranjeevi.rapolu@intel.com&gt;
Tested-by: Chiranjeevi Rapolu &lt;chiranjeevi.rapolu@intel.com&gt;
Signed-off-by: Sakari Ailus &lt;sakari.ailus@linux.intel.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: uvcvideo: Fix 'type' check leading to overflow</title>
<updated>2019-03-13T21:02:26+00:00</updated>
<author>
<name>Alistair Strachan</name>
<email>astrachan@google.com</email>
</author>
<published>2018-12-19T01:32:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac8befb6dd601fd35c1d64167750c6698bc27c80'/>
<id>urn:sha1:ac8befb6dd601fd35c1d64167750c6698bc27c80</id>
<content type='text'>
commit 47bb117911b051bbc90764a8bff96543cbd2005f upstream.

When initially testing the Camera Terminal Descriptor wTerminalType
field (buffer[4]), no mask is used. Later in the function, the MSB is
overloaded to store the descriptor subtype, and so a mask of 0x7fff
is used to check the type.

If a descriptor is specially crafted to set this overloaded bit in the
original wTerminalType field, the initial type check will fail (falling
through, without adjusting the buffer size), but the later type checks
will pass, assuming the buffer has been made suitably large, causing an
overflow.

Avoid this problem by checking for the MSB in the wTerminalType field.
If the bit is set, assume the descriptor is bad, and abort parsing it.

Originally reported here:
https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
A similar (non-compiling) patch was provided at that time.

Reported-by: syzbot &lt;syzkaller@googlegroups.com&gt;
Signed-off-by: Alistair Strachan &lt;astrachan@google.com&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: uvcvideo: Refactor teardown of uvc on USB disconnect</title>
<updated>2019-01-26T08:32:37+00:00</updated>
<author>
<name>Daniel Axtens</name>
<email>dja@axtens.net</email>
</author>
<published>2017-04-23T04:53:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=819e2e0760f3d6d04e07fff7e6328e42da8b3115'/>
<id>urn:sha1:819e2e0760f3d6d04e07fff7e6328e42da8b3115</id>
<content type='text'>
[ Upstream commit 10e1fdb95809ed21406f53b5b4f064673a1b9ceb ]

Currently, disconnecting a USB webcam while it is in use prints out a
number of warnings, such as:

WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90
sysfs group ffffffffa7cd0780 not found for kobject 'event13'

This has been noticed before. [0]

This is because of the order in which things are torn down.

If there are no streams active during a USB disconnect:

 - uvc_disconnect() is invoked via device_del() through the bus
   notifier mechanism.

 - this calls uvc_unregister_video().

 - uvc_unregister_video() unregisters the video device for each
   stream,

 - because there are no streams open, it calls uvc_delete()

 - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
   input device.

 - uvc_delete() calls media_device_unregister(), which cleans up the
   media device

 - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
   return, and we end up back in device_del().

 - device_del() then cleans up the sysfs folder for the camera with
   dpm_sysfs_remove(). Because uvc_status_cleanup() and
   media_device_unregister() have already been called, this all works
   nicely.

If, on the other hand, there *are* streams active during a USB disconnect:

 - uvc_disconnect() is invoked

 - this calls uvc_unregister_video()

 - uvc_unregister_video() unregisters the video device for each
   stream,

 - uvc_unregister_video() and uvc_disconnect() return, and we end up
   back in device_del().

 - device_del() then cleans up the sysfs folder for the camera with
   dpm_sysfs_remove(). Because the status input device and the media
   device are children of the USB device, this also deletes their
   sysfs folders.

 - Sometime later, the final stream is closed, invoking uvc_release().

 - uvc_release() calls uvc_delete()

 - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
   input device. Because the sysfs directory has already been removed,
   this causes a WARNing.

 - uvc_delete() calls media_device_unregister(), which cleans up the
   media device. Because the sysfs directory has already been removed,
   this causes another WARNing.

To fix this, we need to make sure the devices are always unregistered
before the end of uvc_disconnect(). To this, move the unregistration
into the disconnect path:

 - split uvc_status_cleanup() into two parts, one on disconnect that
   unregisters and one on delete that frees.

 - move v4l2_device_unregister() and media_device_unregister() into
   the disconnect path.

[0]: https://lkml.org/lkml/2016/12/8/657

[Renamed uvc_input_cleanup() to uvc_input_unregister()]

Signed-off-by: Daniel Axtens &lt;dja@axtens.net&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: dvb-usb-v2: Fix incorrect use of transfer_flags URB_FREE_BUFFER</title>
<updated>2019-01-09T16:38:40+00:00</updated>
<author>
<name>Malcolm Priestley</name>
<email>tvboxspy@gmail.com</email>
</author>
<published>2018-11-26T20:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80562cf3b1886d59f8a966807b4029e143198dc6'/>
<id>urn:sha1:80562cf3b1886d59f8a966807b4029e143198dc6</id>
<content type='text'>
commit 255095fa7f62ff09b6f61393414535c59c6b4cb0 upstream.

commit 1a0c10ed7bb1 ("media: dvb-usb-v2: stop using coherent memory for
URBs") incorrectly adds URB_FREE_BUFFER after every urb transfer.

It cannot use this flag because it reconfigures the URBs accordingly
to suit connected devices. In doing a call to usb_free_urb is made and
invertedly frees the buffers.

The stream buffer should remain constant while driver is up.

Signed-off-by: Malcolm Priestley &lt;tvboxspy@gmail.com&gt;
CC: stable@vger.kernel.org # v4.18+
Signed-off-by: Sean Young &lt;sean@mess.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: gspca: fix frame overflow error</title>
<updated>2018-12-13T08:16:17+00:00</updated>
<author>
<name>Hans Verkuil</name>
<email>hverkuil@xs4all.nl</email>
</author>
<published>2018-11-20T10:13:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4dabf370838d1cf3bae6e96fc1a02cd39f9404f'/>
<id>urn:sha1:c4dabf370838d1cf3bae6e96fc1a02cd39f9404f</id>
<content type='text'>
commit f96d84488f7d5f9123428c700cea82a292bca53e upstream.

When converting gspca to vb2 I missed that fact that the buffer sizes
were rounded up to the next page size. As a result some gspca drivers
(spca561 being one of them) reported frame overflows.

Modify the code to align the buffer sizes to the next page size, just
as the original code did.

Fixes: 1f5965c4dfd7 ("media: gspca: convert to vb2")
Tested-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Reported-by: softwarebugs &lt;softwarebugs@protonmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;      # for v4.18 and up
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: em28xx: fix handler for vidioc_s_input()</title>
<updated>2018-11-13T19:08:53+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+samsung@kernel.org</email>
</author>
<published>2018-09-14T17:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a79eb1233e27933b351973473311f42b41e4de3'/>
<id>urn:sha1:9a79eb1233e27933b351973473311f42b41e4de3</id>
<content type='text'>
commit 258c430456ba5f0005043762e14fc3be35983aaf upstream.

The a-&gt;index is not the name of the internal amux entry,
but, instead a value from zero to the maximum number
of audio inputs.

As the actual available inputs depend on each board, build
it dynamically.

This is broken for a really long time. On a quick check,
since at least commit 195a4ef627e1 ("V4L/DVB (6585): Convert
em28xx to video_ioctl2") this was not implemented right.

Fixes: 195a4ef627e1 ("V4L/DVB (6585): Convert em28xx to video_ioctl2")

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: em28xx: make v4l2-compliance happier by starting sequence on zero</title>
<updated>2018-11-13T19:08:53+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+samsung@kernel.org</email>
</author>
<published>2018-09-14T02:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e2e4d05b50b5033df9d6bc7527c3fe2566f3884'/>
<id>urn:sha1:3e2e4d05b50b5033df9d6bc7527c3fe2566f3884</id>
<content type='text'>
commit afeaade90db4c5dab93f326d9582be1d5954a198 upstream.

The v4l2-compliance tool complains if a video doesn't start
with a zero sequence number.

While this shouldn't cause any real problem for apps, let's
make it happier, in order to better check the v4l2-compliance
differences before and after patchsets.

This is actually an old issue. It is there since at least its
videobuf2 conversion, e. g. changeset 3829fadc461 ("[media]
em28xx: convert to videobuf2"), if VB1 wouldn't suffer from
the same issue.

Cc: stable@vger.kernel.org
Fixes: d3829fadc461 ("[media] em28xx: convert to videobuf2")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>media: em28xx: fix input name for Terratec AV 350</title>
<updated>2018-11-13T19:08:53+00:00</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+samsung@kernel.org</email>
</author>
<published>2018-09-14T04:20:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d861ec5dfe0cfda7147b1a70df0ed6b19e794c6a'/>
<id>urn:sha1:d861ec5dfe0cfda7147b1a70df0ed6b19e794c6a</id>
<content type='text'>
commit 15644bfa195bd166d0a5ed76ae2d587f719c3dac upstream.

Instead of using a register value, use an AMUX name, as otherwise
VIDIOC_G_AUDIO would fail.

Cc: stable@vger.kernel.org
Fixes: 766ed64de554 ("V4L/DVB (11827): Add support for Terratec Grabster AV350")
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
