kernel/drivers/media/usb, branch linux-5.1.y

media: hdpvr: fix locking and a missing msleep

2019-07-26T07:12:41Z

[ Upstream commit 6bc5a4a1927556ff9adce1aa95ea408c95453225 ] This driver has three locking issues: - The wait_event_interruptible() condition calls hdpvr_get_next_buffer(dev) which uses a mutex, which is not allowed. Rewrite with list_empty_careful() that doesn't need locking. - In hdpvr_read() the call to hdpvr_stop_streaming() didn't lock io_mutex, but it should have since stop_streaming expects that. - In hdpvr_device_release() io_mutex was locked when calling flush_work(), but there it shouldn't take that mutex since the work done by flush_work() also wants to lock that mutex. There are also two other changes (suggested by Keith): - msecs_to_jiffies(4000); (a NOP) should have been msleep(4000). - Change v4l2_dbg to v4l2_info to always log if streaming had to be restarted. Reported-by: Keith Pyle Suggested-by: Keith Pyle Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: uvcvideo: Fix access to uninitialized fields on probe error

2019-07-26T07:12:33Z

[ Upstream commit 11a087f484bf15ff65f0a9f277aa5a61fd07ed2a ] We need to check whether this work we are canceling actually is initialized. Signed-off-by: Oliver Neukum Reported-by: syzbot+2e1ef9188251d9cc7944@syzkaller.appspotmail.com Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: usb:zr364xx:Fix KASAN:null-ptr-deref Read in zr364xx_vidioc_querycap

2019-07-26T07:12:27Z

[ Upstream commit 5d2e73a5f80a5b5aff3caf1ec6d39b5b3f54b26e ] SyzKaller hit the null pointer deref while reading from uninitialized udev->product in zr364xx_vidioc_querycap(). ================================================================== BUG: KASAN: null-ptr-deref in read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 Read of size 1 at addr 0000000000000000 by task v4l_id/5287 CPU: 1 PID: 5287 Comm: v4l_id Not tainted 5.1.0-rc3-319004-g43151d6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 kasan_report.cold+0x5/0x3c mm/kasan/report.c:321 read_word_at_a_time+0xe/0x20 include/linux/compiler.h:274 strscpy+0x8a/0x280 lib/string.c:207 zr364xx_vidioc_querycap+0xb5/0x210 drivers/media/usb/zr364xx/zr364xx.c:706 v4l_querycap+0x12b/0x340 drivers/media/v4l2-core/v4l2-ioctl.c:1062 __video_do_ioctl+0x5bb/0xb40 drivers/media/v4l2-core/v4l2-ioctl.c:2874 video_usercopy+0x44e/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3056 v4l2_ioctl+0x14e/0x1a0 drivers/media/v4l2-core/v4l2-dev.c:364 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xced/0x12f0 fs/ioctl.c:696 ksys_ioctl+0xa0/0xc0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:718 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f3b56d8b347 Code: 90 90 90 48 8b 05 f1 fa 2a 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 90 90 90 90 90 90 90 90 90 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c1 fa 2a 00 31 d2 48 29 c2 64 RSP: 002b:00007ffe005d5d68 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f3b56d8b347 RDX: 00007ffe005d5d70 RSI: 0000000080685600 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000400884 R13: 00007ffe005d5ec0 R14: 0000000000000000 R15: 0000000000000000 ================================================================== For this device udev->product is not initialized and accessing it causes a NULL pointer deref. The fix is to check for NULL before strscpy() and copy empty string, if product is NULL Reported-by: syzbot+66010012fd4c531a1a96@syzkaller.appspotmail.com Signed-off-by: Vandana BN Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: dvb: usb: fix use after free in dvb_usb_device_exit

2019-07-26T07:12:24Z

[ Upstream commit 6cf97230cd5f36b7665099083272595c55d72be7 ] dvb_usb_device_exit() frees and uses the device name in that order. Fix by storing the name in a buffer before freeing it. Signed-off-by: Oliver Neukum Reported-by: syzbot+26ec41e9f788b3eba396@syzkaller.appspotmail.com Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: smsusb: better handle optional alignment

2019-06-09T07:16:08Z

commit a47686636d84eaec5c9c6e84bd5f96bed34d526d upstream. Most Siano devices require an alignment for the response. Changeset f3be52b0056a ("media: usb: siano: Fix general protection fault in smsusb") changed the logic with gets such aligment, but it now produces a sparce warning: drivers/media/usb/siano/smsusb.c: In function 'smsusb_init_device': drivers/media/usb/siano/smsusb.c:447:37: warning: 'in_maxp' may be used uninitialized in this function [-Wmaybe-uninitialized] 447 | dev->response_alignment = in_maxp - sizeof(struct sms_msg_hdr); | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ The sparse message itself is bogus, but a broken (or fake) USB eeprom could produce a negative value for response_alignment. So, change the code in order to check if the result is not negative. Fixes: 31e0456de5be ("media: usb: siano: Fix general protection fault in smsusb") CC: Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: usb: siano: Fix false-positive "uninitialized variable" warning

2019-06-09T07:16:08Z

commit 45457c01171fd1488a7000d1751c06ed8560ee38 upstream. GCC complains about an apparently uninitialized variable recently added to smsusb_init_device(). It's a false positive, but to silence the warning this patch adds a trivial initialization. Signed-off-by: Alan Stern Reported-by: kbuild test robot CC: Signed-off-by: Greg Kroah-Hartman

media: usb: siano: Fix general protection fault in smsusb

2019-06-09T07:16:08Z

commit 31e0456de5be379b10fea0fa94a681057114a96e upstream. The syzkaller USB fuzzer found a general-protection-fault bug in the smsusb part of the Siano DVB driver. The fault occurs during probe because the driver assumes without checking that the device has both IN and OUT endpoints and the IN endpoint is ep1. By slightly rearranging the driver's initialization code, we can make the appropriate checks early on and thus avoid the problem. If the expected endpoints aren't present, the new code safely returns -ENODEV from the probe routine. Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+53f029db71c19a47325a@syzkaller.appspotmail.com CC: Reviewed-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

media: go7007: avoid clang frame overflow warning with KASAN

2019-05-31T13:43:53Z

[ Upstream commit ed713a4a1367aca5c0f2f329579465db00c17995 ] clang-8 warns about one function here when KASAN is enabled, even without the 'asan-stack' option: drivers/media/usb/go7007/go7007-fw.c:1551:5: warning: stack frame size of 2656 bytes in function I have reported this issue in the llvm bugzilla, but to make it work with the clang-8 release, a small annotation is still needed. Link: https://bugs.llvm.org/show_bug.cgi?id=38809 Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil [hverkuil-cisco@xs4all.nl: fix checkpatch warning] Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: gspca: do not resubmit URBs when streaming has stopped

2019-05-31T13:43:53Z

[ Upstream commit e6f8bd59c28f758feea403a70d6c3ef28c50959f ] When streaming is stopped all URBs are killed, but in fill_frame and in bulk_irq this results in an attempt to resubmit the killed URB. That is not what you want and causes spurious kernel messages. So check if streaming has stopped before resubmitting. Also check against gspca_dev->streaming rather than vb2_start_streaming_called() since vb2_start_streaming_called() will return true when in stop_streaming, but gspca_dev->streaming is set to false when stop_streaming is called. Fixes: 6992effe5344 ("gspca: Kill all URBs before releasing any of them") Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: dvbsky: Avoid leaking dvb frontend

2019-05-31T13:43:52Z

[ Upstream commit fdfa59cd63b184e1e96d51ff170fcac739bc6f6f ] Commit 14f4eaeddabc ("media: dvbsky: fix driver unregister logic") fixed a use-after-free by removing the reference to the frontend after deleting the backing i2c device. This has the unfortunate side effect the frontend device is never freed in the dvb core leaving a dangling device, leading to errors when the dvb core tries to register the frontend after e.g. a replug as reported here: https://www.spinics.net/lists/linux-media/msg138181.html media: dvbsky: issues with DVBSky T680CI === [ 561.119145] sp2 8-0040: CIMaX SP2 successfully attached [ 561.119161] usb 2-3: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 561.119174] sysfs: cannot create duplicate filename '/class/dvb/ dvb0.frontend0' === The use after free happened as dvb_usbv2_disconnect calls in this order: - dvb_usb_device::props->exit(...) - dvb_usbv2_adapter_frontend_exit(...) + if (fe) dvb_unregister_frontend(fe) + dvb_usb_device::props->frontend_detach(...) Moving the release of the i2c device from exit() to frontend_detach() avoids the dangling pointer access and allows the core to unregister the frontend. This was originally reported for a DVBSky T680CI, but it also affects the MyGica T230C. As all supported devices structure the registration/ unregistration identically, apply the change for all device types. Signed-off-by: Stefan Brüns Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin