KASAN: use-after-free Read in usbvision_v4l2_open

KASAN: use-after-free Read in usbvision_v4l2_open

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
git tree:       https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
dashboard link: https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: use-after-free in __mutex_lock_common  
kernel/locking/mutex.c:1043 [inline]
BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360  
kernel/locking/mutex.c:1106
Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526

CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
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+0xef/0x16e lib/dump_stack.c:118
  print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
  __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
  kasan_report+0xe/0x20 mm/kasan/common.c:638
  __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
  __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
  usbvision_v4l2_open+0x77/0x340  
drivers/media/usb/usbvision/usbvision-video.c:314
  v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
  chrdev_open+0x219/0x5c0 fs/char_dev.c:414
  do_dentry_open+0x494/0x1120 fs/open.c:797
  do_last fs/namei.c:3412 [inline]
  path_openat+0x142b/0x4030 fs/namei.c:3529
  do_filp_open+0x1a1/0x280 fs/namei.c:3559
  do_sys_open+0x3c0/0x580 fs/open.c:1097
  do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f70d3cab120
Code: 48 8b 15 1b 4d 2b 00 f7 d8 64 89 02 83 c8 ff c3 90 90 90 90 90 90 90  
90 90 90 83 3d d5 a4 2b 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff  
ff 73 31 c3 48 83 ec 08 e8 5e 8c 01 00 48 89 04 24
RSP: 002b:00007ffc46d40ca8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 00007ffc46d40e08 RCX: 00007f70d3cab120
RDX: 00007f70d3f60138 RSI: 0000000000000000 RDI: 00007ffc46d42f1d
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400884
R13: 00007ffc46d40e00 R14: 0000000000000000 R15: 0000000000000000

Allocated by task 12:
  save_stack+0x1b/0x80 mm/kasan/common.c:71
  set_track mm/kasan/common.c:79 [inline]
  __kasan_kmalloc mm/kasan/common.c:512 [inline]
  __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:485
  kmalloc include/linux/slab.h:556 [inline]
  kzalloc include/linux/slab.h:670 [inline]
  usbvision_alloc drivers/media/usb/usbvision/usbvision-video.c:1315 [inline]
  usbvision_probe.cold+0x5c5/0x1f1e  
drivers/media/usb/usbvision/usbvision-video.c:1469
  usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
  really_probe+0x281/0x6d0 drivers/base/dd.c:548
  driver_probe_device+0x104/0x210 drivers/base/dd.c:721
  __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
  bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430
  __device_attach+0x217/0x360 drivers/base/dd.c:894
  bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490
  device_add+0x1480/0x1c20 drivers/base/core.c:2487
  usb_set_configuration+0xe67/0x1740 drivers/usb/core/message.c:2023
  generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
  usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
  really_probe+0x281/0x6d0 drivers/base/dd.c:548
  driver_probe_device+0x104/0x210 drivers/base/dd.c:721
  __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828
  bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430
  __device_attach+0x217/0x360 drivers/base/dd.c:894
  bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490
  device_add+0x1480/0x1c20 drivers/base/core.c:2487
  usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2537
  hub_port_connect drivers/usb/core/hub.c:5184 [inline]
  hub_port_connect_change drivers/usb/core/hub.c:5324 [inline]
  port_event drivers/usb/core/hub.c:5470 [inline]
  hub_event+0x1e59/0x3860 drivers/usb/core/hub.c:5552
  process_one_work+0x92b/0x1530 kernel/workqueue.c:2264
  worker_thread+0x96/0xe20 kernel/workqueue.c:2410
  kthread+0x318/0x420 kernel/kthread.c:255
  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

Freed by task 3310:
  save_stack+0x1b/0x80 mm/kasan/common.c:71
  set_track mm/kasan/common.c:79 [inline]
  kasan_set_free_info mm/kasan/common.c:334 [inline]
  __kasan_slab_free+0x130/0x180 mm/kasan/common.c:473
  slab_free_hook mm/slub.c:1425 [inline]
  slab_free_freelist_hook mm/slub.c:1458 [inline]
  slab_free mm/slub.c:3005 [inline]
  kfree+0xdc/0x310 mm/slub.c:3957
  usbvision_release+0x181/0x1c0  
drivers/media/usb/usbvision/usbvision-video.c:1364
  usbvision_disconnect+0x171/0x1e0  
drivers/media/usb/usbvision/usbvision-video.c:1589
  usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:423
  __device_release_driver drivers/base/dd.c:1134 [inline]
  device_release_driver_internal+0x42f/0x500 drivers/base/dd.c:1165
  bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:532
  device_del+0x481/0xd30 drivers/base/core.c:2664
  usb_disable_device+0x211/0x690 drivers/usb/core/message.c:1237
  usb_disconnect+0x284/0x8d0 drivers/usb/core/hub.c:2200
  hub_port_connect drivers/usb/core/hub.c:5035 [inline]
  hub_port_connect_change drivers/usb/core/hub.c:5324 [inline]
  port_event drivers/usb/core/hub.c:5470 [inline]
  hub_event+0x1753/0x3860 drivers/usb/core/hub.c:5552
  process_one_work+0x92b/0x1530 kernel/workqueue.c:2264
  worker_thread+0x96/0xe20 kernel/workqueue.c:2410
  kthread+0x318/0x420 kernel/kthread.c:255
  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

The buggy address belongs to the object at ffff8881cad4c000
  which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 6328 bytes inside of
  8192-byte region [ffff8881cad4c000, ffff8881cad4e000)
The buggy address belongs to the page:
page:ffffea00072b5200 refcount:1 mapcount:0 mapping:ffff8881da40c500  
index:0x0 compound_mapcount: 0
raw: 0200000000010200 ffffea0007249a00 0000000200000002 ffff8881da40c500
raw: 0000000000000000 0000000080020002 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff8881cad4d780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881cad4d800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881cad4d880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                         ^
  ffff8881cad4d900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8881cad4d980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Alan Stern]

On Mon, 9 Dec 2019, syzbot wrote:

> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> git tree:       https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> dashboard link: https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> 
> Unfortunately, I don't have any reproducer for this crash yet.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KASAN: use-after-free in __mutex_lock_common  
> kernel/locking/mutex.c:1043 [inline]
> BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360  
> kernel/locking/mutex.c:1106
> Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526
> 
> CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
> 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+0xef/0x16e lib/dump_stack.c:118
>   print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
>   __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
>   kasan_report+0xe/0x20 mm/kasan/common.c:638
>   __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
>   __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
>   usbvision_v4l2_open+0x77/0x340  
> drivers/media/usb/usbvision/usbvision-video.c:314
>   v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
>   chrdev_open+0x219/0x5c0 fs/char_dev.c:414
>   do_dentry_open+0x494/0x1120 fs/open.c:797
>   do_last fs/namei.c:3412 [inline]
>   path_openat+0x142b/0x4030 fs/namei.c:3529
>   do_filp_open+0x1a1/0x280 fs/namei.c:3559
>   do_sys_open+0x3c0/0x580 fs/open.c:1097
>   do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe

This looks like a race in v4l2_open(): The function drops the
videodev_lock mutex before calling the video driver's open routine, and
the device can be unregistered during the short time between.

This patch tries to make the race much more likely to happen, for 
testing and verification.

Andrey, will syzbot run the same test with this patch, even though it 
says it doesn't have a reproducer?

Alan Stern

#syz test: https://github.com/google/kasan.git 1f22d15c

Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
===================================================================
--- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
+++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
@@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
 		wake_up_interruptible(&usbvision->wait_frame);
 		wake_up_interruptible(&usbvision->wait_stream);
 	} else {
+		msleep(100);
 		usbvision_release(usbvision);
 	}
 
Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
===================================================================
--- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
+++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
@@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
 	video_get(vdev);
 	mutex_unlock(&videodev_lock);
 	if (vdev->fops->open) {
-		if (video_is_registered(vdev))
+		if (video_is_registered(vdev)) {
+			msleep(200);
 			ret = vdev->fops->open(filp);
-		else
+		} else
 			ret = -ENODEV;
 	}
 

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[syzbot]

> On Mon, 9 Dec 2019, syzbot wrote:

>> Hello,

>> syzbot found the following crash on:

>> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
>> git tree:       https://github.com/google/kasan.git usb-fuzzer
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
>> kernel config:   
>> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
>> dashboard link:  
>> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
>> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

>> Unfortunately, I don't have any reproducer for this crash yet.

>> IMPORTANT: if you fix the bug, please add the following tag to the  
>> commit:
>> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com

>> ==================================================================
>> BUG: KASAN: use-after-free in __mutex_lock_common
>> kernel/locking/mutex.c:1043 [inline]
>> BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360
>> kernel/locking/mutex.c:1106
>> Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526

>> CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
>> 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+0xef/0x16e lib/dump_stack.c:118
>>    print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
>>    __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
>>    kasan_report+0xe/0x20 mm/kasan/common.c:638
>>    __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
>>    __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
>>    usbvision_v4l2_open+0x77/0x340
>> drivers/media/usb/usbvision/usbvision-video.c:314
>>    v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
>>    chrdev_open+0x219/0x5c0 fs/char_dev.c:414
>>    do_dentry_open+0x494/0x1120 fs/open.c:797
>>    do_last fs/namei.c:3412 [inline]
>>    path_openat+0x142b/0x4030 fs/namei.c:3529
>>    do_filp_open+0x1a1/0x280 fs/namei.c:3559
>>    do_sys_open+0x3c0/0x580 fs/open.c:1097
>>    do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
>>    entry_SYSCALL_64_after_hwframe+0x49/0xbe

> This looks like a race in v4l2_open(): The function drops the
> videodev_lock mutex before calling the video driver's open routine, and
> the device can be unregistered during the short time between.

> This patch tries to make the race much more likely to happen, for
> testing and verification.

> Andrey, will syzbot run the same test with this patch, even though it
> says it doesn't have a reproducer?

> Alan Stern

> #syz test: https://github.com/google/kasan.git 1f22d15c

This crash does not have a reproducer. I cannot test it.


> Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> ===================================================================
> --- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
> +++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> @@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
>   		wake_up_interruptible(&usbvision->wait_frame);
>   		wake_up_interruptible(&usbvision->wait_stream);
>   	} else {
> +		msleep(100);
>   		usbvision_release(usbvision);
>   	}

> Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> ===================================================================
> --- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
> +++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> @@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
>   	video_get(vdev);
>   	mutex_unlock(&videodev_lock);
>   	if (vdev->fops->open) {
> -		if (video_is_registered(vdev))
> +		if (video_is_registered(vdev)) {
> +			msleep(200);
>   			ret = vdev->fops->open(filp);
> -		else
> +		} else
>   			ret = -ENODEV;
>   	}

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[syzbot]

> On Mon, 9 Dec 2019, syzbot wrote:

>> Hello,

>> syzbot found the following crash on:

>> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
>> git tree:       https://github.com/google/kasan.git usb-fuzzer
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
>> kernel config:   
>> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
>> dashboard link:  
>> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
>> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

>> Unfortunately, I don't have any reproducer for this crash yet.

>> IMPORTANT: if you fix the bug, please add the following tag to the  
>> commit:
>> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com

>> ==================================================================
>> BUG: KASAN: use-after-free in __mutex_lock_common
>> kernel/locking/mutex.c:1043 [inline]
>> BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360
>> kernel/locking/mutex.c:1106
>> Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526

>> CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
>> 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+0xef/0x16e lib/dump_stack.c:118
>>    print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
>>    __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
>>    kasan_report+0xe/0x20 mm/kasan/common.c:638
>>    __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
>>    __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
>>    usbvision_v4l2_open+0x77/0x340
>> drivers/media/usb/usbvision/usbvision-video.c:314
>>    v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
>>    chrdev_open+0x219/0x5c0 fs/char_dev.c:414
>>    do_dentry_open+0x494/0x1120 fs/open.c:797
>>    do_last fs/namei.c:3412 [inline]
>>    path_openat+0x142b/0x4030 fs/namei.c:3529
>>    do_filp_open+0x1a1/0x280 fs/namei.c:3559
>>    do_sys_open+0x3c0/0x580 fs/open.c:1097
>>    do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
>>    entry_SYSCALL_64_after_hwframe+0x49/0xbe

> This looks like a race in v4l2_open(): The function drops the
> videodev_lock mutex before calling the video driver's open routine, and
> the device can be unregistered during the short time between.

> This patch tries to make the race much more likely to happen, for
> testing and verification.

> Andrey, will syzbot run the same test with this patch, even though it
> says it doesn't have a reproducer?

> Alan Stern

> #syz test: https://github.com/google/kasan.git 1f22d15c

This crash does not have a reproducer. I cannot test it.


> Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> ===================================================================
> --- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
> +++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> @@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
>   		wake_up_interruptible(&usbvision->wait_frame);
>   		wake_up_interruptible(&usbvision->wait_stream);
>   	} else {
> +		msleep(100);
>   		usbvision_release(usbvision);
>   	}

> Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> ===================================================================
> --- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
> +++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> @@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
>   	video_get(vdev);
>   	mutex_unlock(&videodev_lock);
>   	if (vdev->fops->open) {
> -		if (video_is_registered(vdev))
> +		if (video_is_registered(vdev)) {
> +			msleep(200);
>   			ret = vdev->fops->open(filp);
> -		else
> +		} else
>   			ret = -ENODEV;
>   	}

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Andrey Konovalov]

On Tue, Dec 10, 2019 at 8:48 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Mon, 9 Dec 2019, syzbot wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> > git tree:       https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> > dashboard link: https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in __mutex_lock_common
> > kernel/locking/mutex.c:1043 [inline]
> > BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360
> > kernel/locking/mutex.c:1106
> > Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526
> >
> > CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
> > 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+0xef/0x16e lib/dump_stack.c:118
> >   print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
> >   __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
> >   kasan_report+0xe/0x20 mm/kasan/common.c:638
> >   __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
> >   __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
> >   usbvision_v4l2_open+0x77/0x340
> > drivers/media/usb/usbvision/usbvision-video.c:314
> >   v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
> >   chrdev_open+0x219/0x5c0 fs/char_dev.c:414
> >   do_dentry_open+0x494/0x1120 fs/open.c:797
> >   do_last fs/namei.c:3412 [inline]
> >   path_openat+0x142b/0x4030 fs/namei.c:3529
> >   do_filp_open+0x1a1/0x280 fs/namei.c:3559
> >   do_sys_open+0x3c0/0x580 fs/open.c:1097
> >   do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
> >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> This looks like a race in v4l2_open(): The function drops the
> videodev_lock mutex before calling the video driver's open routine, and
> the device can be unregistered during the short time between.
>
> This patch tries to make the race much more likely to happen, for
> testing and verification.
>
> Andrey, will syzbot run the same test with this patch, even though it
> says it doesn't have a reproducer?

Hi Alan,

No, unfortunately there's nothing to run if there's no reproducer.
It's technically possible to run the same program log that triggered
the bug initially, but since the bug wasn't reproduced with this log
even without the patch, there isn't much sense in running it with the
patch applied.

Thanks!

>
> Alan Stern
>
> #syz test: https://github.com/google/kasan.git 1f22d15c
>
> Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> ===================================================================
> --- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
> +++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> @@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
>                 wake_up_interruptible(&usbvision->wait_frame);
>                 wake_up_interruptible(&usbvision->wait_stream);
>         } else {
> +               msleep(100);
>                 usbvision_release(usbvision);
>         }
>
> Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> ===================================================================
> --- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
> +++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> @@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
>         video_get(vdev);
>         mutex_unlock(&videodev_lock);
>         if (vdev->fops->open) {
> -               if (video_is_registered(vdev))
> +               if (video_is_registered(vdev)) {
> +                       msleep(200);
>                         ret = vdev->fops->open(filp);
> -               else
> +               } else
>                         ret = -ENODEV;
>         }
>
>

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Alan Stern]

On Tue, 10 Dec 2019, Andrey Konovalov wrote:

> On Tue, Dec 10, 2019 at 8:48 PM Alan Stern <stern@rowland.harvard.edu> wrote:

> > This looks like a race in v4l2_open(): The function drops the
> > videodev_lock mutex before calling the video driver's open routine, and
> > the device can be unregistered during the short time between.
> >
> > This patch tries to make the race much more likely to happen, for
> > testing and verification.
> >
> > Andrey, will syzbot run the same test with this patch, even though it
> > says it doesn't have a reproducer?
> 
> Hi Alan,
> 
> No, unfortunately there's nothing to run if there's no reproducer.
> It's technically possible to run the same program log that triggered
> the bug initially, but since the bug wasn't reproduced with this log
> even without the patch, there isn't much sense in running it with the
> patch applied.

Actually it does make sense.  That bug was caused by a race, and the 
patch tries to make the race much more likely to happen, so the same 
test should fail again.

But never mind; I'll try a different approach.  There's another syzbot
bug report, one with a reproducer, and with this patch in place it
should trigger the same race.  I'll try submitting it that way.

By the way, do you know why syzbot sent _two_ reply messages?  One with 
message ID <00000000000031a0af05995eca0b@google.com> and the other with 
message ID <000000000000441a4205995eca11@google.com>?  It seems like 
overkill.

Alan Stern

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Alan Stern]

On Tue, 10 Dec 2019, syzbot wrote:

> > On Mon, 9 Dec 2019, syzbot wrote:
> 
> >> Hello,
> 
> >> syzbot found the following crash on:
> 
> >> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> >> git tree:       https://github.com/google/kasan.git usb-fuzzer
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> >> kernel config:   
> >> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> >> dashboard link:  
> >> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> >> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> 
> >> Unfortunately, I don't have any reproducer for this crash yet.
> 
> >> IMPORTANT: if you fix the bug, please add the following tag to the  
> >> commit:
> >> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com
> 
> >> ==================================================================
> >> BUG: KASAN: use-after-free in __mutex_lock_common
> >> kernel/locking/mutex.c:1043 [inline]
> >> BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360
> >> kernel/locking/mutex.c:1106
> >> Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526
> 
> >> CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
> >> 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+0xef/0x16e lib/dump_stack.c:118
> >>    print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
> >>    __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
> >>    kasan_report+0xe/0x20 mm/kasan/common.c:638
> >>    __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
> >>    __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
> >>    usbvision_v4l2_open+0x77/0x340
> >> drivers/media/usb/usbvision/usbvision-video.c:314
> >>    v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
> >>    chrdev_open+0x219/0x5c0 fs/char_dev.c:414
> >>    do_dentry_open+0x494/0x1120 fs/open.c:797
> >>    do_last fs/namei.c:3412 [inline]
> >>    path_openat+0x142b/0x4030 fs/namei.c:3529
> >>    do_filp_open+0x1a1/0x280 fs/namei.c:3559
> >>    do_sys_open+0x3c0/0x580 fs/open.c:1097
> >>    do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
> >>    entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> > This looks like a race in v4l2_open(): The function drops the
> > videodev_lock mutex before calling the video driver's open routine, and
> > the device can be unregistered during the short time between.
> 
> > This patch tries to make the race much more likely to happen, for
> > testing and verification.
> 
> > Andrey, will syzbot run the same test with this patch, even though it
> > says it doesn't have a reproducer?
> 
> > Alan Stern
> 
> > #syz test: https://github.com/google/kasan.git 1f22d15c
> 
> This crash does not have a reproducer. I cannot test it.

Let's try the same patch with a different bug report -- one that has a
reproducer.  I assume that syzbot gets the bug identity from the
email's From: line (which has been updated acoordingly) rather than the 
Subject: line.

#syz test: https://github.com/google/kasan.git 1f22d15c

Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
===================================================================
--- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
+++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
@@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
 		wake_up_interruptible(&usbvision->wait_frame);
 		wake_up_interruptible(&usbvision->wait_stream);
 	} else {
+		msleep(100);
 		usbvision_release(usbvision);
 	}
 
Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
===================================================================
--- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
+++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
@@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
 	video_get(vdev);
 	mutex_unlock(&videodev_lock);
 	if (vdev->fops->open) {
-		if (video_is_registered(vdev))
+		if (video_is_registered(vdev)) {
+			msleep(200);
 			ret = vdev->fops->open(filp);
-		else
+		} else
 			ret = -ENODEV;
 	}
 

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Andrey Konovalov]

On Tue, Dec 10, 2019 at 9:13 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Tue, 10 Dec 2019, Andrey Konovalov wrote:
>
> > On Tue, Dec 10, 2019 at 8:48 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> > > This looks like a race in v4l2_open(): The function drops the
> > > videodev_lock mutex before calling the video driver's open routine, and
> > > the device can be unregistered during the short time between.
> > >
> > > This patch tries to make the race much more likely to happen, for
> > > testing and verification.
> > >
> > > Andrey, will syzbot run the same test with this patch, even though it
> > > says it doesn't have a reproducer?
> >
> > Hi Alan,
> >
> > No, unfortunately there's nothing to run if there's no reproducer.
> > It's technically possible to run the same program log that triggered
> > the bug initially, but since the bug wasn't reproduced with this log
> > even without the patch, there isn't much sense in running it with the
> > patch applied.
>
> Actually it does make sense.  That bug was caused by a race, and the
> patch tries to make the race much more likely to happen, so the same
> test should fail again.
>
> But never mind; I'll try a different approach.  There's another syzbot
> bug report, one with a reproducer, and with this patch in place it
> should trigger the same race.  I'll try submitting it that way.
>
> By the way, do you know why syzbot sent _two_ reply messages?  One with
> message ID <00000000000031a0af05995eca0b@google.com> and the other with
> message ID <000000000000441a4205995eca11@google.com>?  It seems like
> overkill.

Hm, I'm not sure. Dmitry?

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Andrey Konovalov]

On Tue, Dec 10, 2019 at 9:17 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Tue, 10 Dec 2019, syzbot wrote:
>
> > > On Mon, 9 Dec 2019, syzbot wrote:
> >
> > >> Hello,
> >
> > >> syzbot found the following crash on:
> >
> > >> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> > >> git tree:       https://github.com/google/kasan.git usb-fuzzer
> > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> > >> kernel config:
> > >> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> > >> dashboard link:
> > >> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> > >> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > >> Unfortunately, I don't have any reproducer for this crash yet.
> >
> > >> IMPORTANT: if you fix the bug, please add the following tag to the
> > >> commit:
> > >> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com
> >
> > >> ==================================================================
> > >> BUG: KASAN: use-after-free in __mutex_lock_common
> > >> kernel/locking/mutex.c:1043 [inline]
> > >> BUG: KASAN: use-after-free in __mutex_lock+0x124d/0x1360
> > >> kernel/locking/mutex.c:1106
> > >> Read of size 8 at addr ffff8881cad4d8b8 by task v4l_id/4526
> >
> > >> CPU: 0 PID: 4526 Comm: v4l_id Not tainted 5.4.0-syzkaller #0
> > >> 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+0xef/0x16e lib/dump_stack.c:118
> > >>    print_address_description.constprop.0+0x36/0x50 mm/kasan/report.c:374
> > >>    __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:506
> > >>    kasan_report+0xe/0x20 mm/kasan/common.c:638
> > >>    __mutex_lock_common kernel/locking/mutex.c:1043 [inline]
> > >>    __mutex_lock+0x124d/0x1360 kernel/locking/mutex.c:1106
> > >>    usbvision_v4l2_open+0x77/0x340
> > >> drivers/media/usb/usbvision/usbvision-video.c:314
> > >>    v4l2_open+0x20f/0x3d0 drivers/media/v4l2-core/v4l2-dev.c:423
> > >>    chrdev_open+0x219/0x5c0 fs/char_dev.c:414
> > >>    do_dentry_open+0x494/0x1120 fs/open.c:797
> > >>    do_last fs/namei.c:3412 [inline]
> > >>    path_openat+0x142b/0x4030 fs/namei.c:3529
> > >>    do_filp_open+0x1a1/0x280 fs/namei.c:3559
> > >>    do_sys_open+0x3c0/0x580 fs/open.c:1097
> > >>    do_syscall_64+0xb7/0x5b0 arch/x86/entry/common.c:294
> > >>    entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > > This looks like a race in v4l2_open(): The function drops the
> > > videodev_lock mutex before calling the video driver's open routine, and
> > > the device can be unregistered during the short time between.
> >
> > > This patch tries to make the race much more likely to happen, for
> > > testing and verification.
> >
> > > Andrey, will syzbot run the same test with this patch, even though it
> > > says it doesn't have a reproducer?
> >
> > > Alan Stern
> >
> > > #syz test: https://github.com/google/kasan.git 1f22d15c
> >
> > This crash does not have a reproducer. I cannot test it.
>
> Let's try the same patch with a different bug report -- one that has a
> reproducer.  I assume that syzbot gets the bug identity from the
> email's From: line (which has been updated acoordingly) rather than the
> Subject: line.

Did you get a response for this test? I see the test attempt on the
dashboard (the patch failed to build), but I didn't get an email with
the result.

>
> #syz test: https://github.com/google/kasan.git 1f22d15c
>
> Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> ===================================================================
> --- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
> +++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
> @@ -1585,6 +1585,7 @@ static void usbvision_disconnect(struct
>                 wake_up_interruptible(&usbvision->wait_frame);
>                 wake_up_interruptible(&usbvision->wait_stream);
>         } else {
> +               msleep(100);
>                 usbvision_release(usbvision);
>         }
>
> Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> ===================================================================
> --- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
> +++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
> @@ -419,9 +419,10 @@ static int v4l2_open(struct inode *inode
>         video_get(vdev);
>         mutex_unlock(&videodev_lock);
>         if (vdev->fops->open) {
> -               if (video_is_registered(vdev))
> +               if (video_is_registered(vdev)) {
> +                       msleep(200);
>                         ret = vdev->fops->open(filp);
> -               else
> +               } else
>                         ret = -ENODEV;
>         }
>
>

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Alan Stern]

On Wed, 11 Dec 2019, Andrey Konovalov wrote:

> On Tue, Dec 10, 2019 at 9:17 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Tue, 10 Dec 2019, syzbot wrote:
> >
> > > > On Mon, 9 Dec 2019, syzbot wrote:
> > >
> > > >> Hello,
> > >
> > > >> syzbot found the following crash on:
> > >
> > > >> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> > > >> git tree:       https://github.com/google/kasan.git usb-fuzzer
> > > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> > > >> kernel config:
> > > >> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> > > >> dashboard link:
> > > >> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> > > >> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > >> Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > >> IMPORTANT: if you fix the bug, please add the following tag to the
> > > >> commit:
> > > >> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com

> > > This crash does not have a reproducer. I cannot test it.
> >
> > Let's try the same patch with a different bug report -- one that has a
> > reproducer.  I assume that syzbot gets the bug identity from the
> > email's From: line (which has been updated acoordingly) rather than the
> > Subject: line.
> 
> Did you get a response for this test? I see the test attempt on the
> dashboard (the patch failed to build), but I didn't get an email with
> the result.

No response so far.  On the other hand, syzbot has been a bit slow to 
respond to my tests recently (typical turnaround time is several 
hours).  I don't know what's going on.

Alan Stern

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Dmitry Vyukov]

On Wed, Dec 11, 2019 at 3:23 PM Andrey Konovalov <andreyknvl@google.com> wrote:
>
> On Tue, Dec 10, 2019 at 9:13 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > On Tue, 10 Dec 2019, Andrey Konovalov wrote:
> >
> > > On Tue, Dec 10, 2019 at 8:48 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > > This looks like a race in v4l2_open(): The function drops the
> > > > videodev_lock mutex before calling the video driver's open routine, and
> > > > the device can be unregistered during the short time between.
> > > >
> > > > This patch tries to make the race much more likely to happen, for
> > > > testing and verification.
> > > >
> > > > Andrey, will syzbot run the same test with this patch, even though it
> > > > says it doesn't have a reproducer?
> > >
> > > Hi Alan,
> > >
> > > No, unfortunately there's nothing to run if there's no reproducer.
> > > It's technically possible to run the same program log that triggered
> > > the bug initially, but since the bug wasn't reproduced with this log
> > > even without the patch, there isn't much sense in running it with the
> > > patch applied.
> >
> > Actually it does make sense.  That bug was caused by a race, and the
> > patch tries to make the race much more likely to happen, so the same
> > test should fail again.
> >
> > But never mind; I'll try a different approach.  There's another syzbot
> > bug report, one with a reproducer, and with this patch in place it
> > should trigger the same race.  I'll try submitting it that way.
> >
> > By the way, do you know why syzbot sent _two_ reply messages?  One with
> > message ID <00000000000031a0af05995eca0b@google.com> and the other with
> > message ID <000000000000441a4205995eca11@google.com>?  It seems like
> > overkill.
>
> Hm, I'm not sure. Dmitry?

I would assume it received 2 emails (second from syzkaller-bugs@
mailing list) and deduplication logic did not work somehow. So it
replied to both.

Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Dmitry Vyukov]

On Wed, Dec 11, 2019 at 4:15 PM Alan Stern <stern@rowland.harvard.edu> wrote
>
> On Wed, 11 Dec 2019, Andrey Konovalov wrote:
>
> > On Tue, Dec 10, 2019 at 9:17 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Tue, 10 Dec 2019, syzbot wrote:
> > >
> > > > > On Mon, 9 Dec 2019, syzbot wrote:
> > > >
> > > > >> Hello,
> > > >
> > > > >> syzbot found the following crash on:
> > > >
> > > > >> HEAD commit:    1f22d15c usb: gadget: add raw-gadget interface
> > > > >> git tree:       https://github.com/google/kasan.git usb-fuzzer
> > > > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1296f42ae00000
> > > > >> kernel config:
> > > > >> https://syzkaller.appspot.com/x/.config?x=8ccee2968018adcb
> > > > >> dashboard link:
> > > > >> https://syzkaller.appspot.com/bug?extid=c7b0ec009a216143df30
> > > > >> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > > >
> > > > >> Unfortunately, I don't have any reproducer for this crash yet.
> > > >
> > > > >> IMPORTANT: if you fix the bug, please add the following tag to the
> > > > >> commit:
> > > > >> Reported-by: syzbot+c7b0ec009a216143df30@syzkaller.appspotmail.com
>
> > > > This crash does not have a reproducer. I cannot test it.
> > >
> > > Let's try the same patch with a different bug report -- one that has a
> > > reproducer.  I assume that syzbot gets the bug identity from the
> > > email's From: line (which has been updated acoordingly) rather than the
> > > Subject: line.
> >
> > Did you get a response for this test? I see the test attempt on the
> > dashboard (the patch failed to build), but I didn't get an email with
> > the result.
>
> No response so far.  On the other hand, syzbot has been a bit slow to
> respond to my tests recently (typical turnaround time is several
> hours).  I don't know what's going on.

The system is busy with bisections. Patch testing takes precedence
over bisection, but only after the current one finished. Bisections
can take a long time, up to days. The way it all works is a total hack
that one can put together in a few days.

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Alan Stern]

On Wed, 11 Dec 2019, Dmitry Vyukov wrote:

> > > By the way, do you know why syzbot sent _two_ reply messages?  One with
> > > message ID <00000000000031a0af05995eca0b@google.com> and the other with
> > > message ID <000000000000441a4205995eca11@google.com>?  It seems like
> > > overkill.
> >
> > Hm, I'm not sure. Dmitry?
> 
> I would assume it received 2 emails (second from syzkaller-bugs@
> mailing list) and deduplication logic did not work somehow. So it
> replied to both.

Does that mean when I send in a test request, it's better to omit 
syzkaller-bugs from the CC: list?

Also, whatever did happen to the most recent test request (the one sent 
to syzbot+7fa38a608b1075dfd634 even though it was meant to test the 
bug reported by syzbot+c7b0ec009a216143df30)?  Did it truly fail to 
build?  I can't find anything about it in the dashboard link for either 
bug report, and I haven't gotten a reply from syzbot.

Alan Stern

Re: KASAN: use-after-free Read in usbvision_v4l2_open

[Andrey Konovalov]

On Wed, Dec 11, 2019 at 5:22 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 11 Dec 2019, Dmitry Vyukov wrote:
>
> > > > By the way, do you know why syzbot sent _two_ reply messages?  One with
> > > > message ID <00000000000031a0af05995eca0b@google.com> and the other with
> > > > message ID <000000000000441a4205995eca11@google.com>?  It seems like
> > > > overkill.
> > >
> > > Hm, I'm not sure. Dmitry?
> >
> > I would assume it received 2 emails (second from syzkaller-bugs@
> > mailing list) and deduplication logic did not work somehow. So it
> > replied to both.
>
> Does that mean when I send in a test request, it's better to omit
> syzkaller-bugs from the CC: list?
>
> Also, whatever did happen to the most recent test request (the one sent
> to syzbot+7fa38a608b1075dfd634 even though it was meant to test the
> bug reported by syzbot+c7b0ec009a216143df30)?  Did it truly fail to
> build?  I can't find anything about it in the dashboard link for either
> bug report, and I haven't gotten a reply from syzbot.

Yes, the patch failed due to msleep() being undefined in that source
file. I'm not sure why syzbot didn't send a response. Could you try
resending the patch as the reply to that other syzbot report?

Re: general protection fault in usb_set_interface

[Alan Stern]

[CC: list trimmed slightly -- including syzkaller-bugs]

On Thu, 12 Dec 2019, Andrey Konovalov wrote:

> Yes, the patch failed due to msleep() being undefined in that source
> file. I'm not sure why syzbot didn't send a response. Could you try 
> resending the patch as the reply to that other syzbot report?

This isn't literally a reply to the other syzbot report because I no 
longer have any copies of it in my mailbox.  But it uses the same To: 
and Subject: lines, so hopefully it will be okay.

This version of the patch adds #include <linux/delay.h>, so now
msleep() should be declared and there won't be any build errors.

If you want me to send the old version that fails to build, let me 
know.

Alan Stern

#syz test: https://github.com/google/kasan.git 1f22d15c

Index: usb-devel/drivers/media/usb/usbvision/usbvision-video.c
===================================================================
--- usb-devel.orig/drivers/media/usb/usbvision/usbvision-video.c
+++ usb-devel/drivers/media/usb/usbvision/usbvision-video.c
@@ -49,6 +49,7 @@
 #include <media/tuner.h>
 
 #include <linux/workqueue.h>
+#include <linux/delay.h>
 
 #include "usbvision.h"
 #include "usbvision-cards.h"
@@ -1585,6 +1586,7 @@ static void usbvision_disconnect(struct
 		wake_up_interruptible(&usbvision->wait_frame);
 		wake_up_interruptible(&usbvision->wait_stream);
 	} else {
+		msleep(100);
 		usbvision_release(usbvision);
 	}
 
Index: usb-devel/drivers/media/v4l2-core/v4l2-dev.c
===================================================================
--- usb-devel.orig/drivers/media/v4l2-core/v4l2-dev.c
+++ usb-devel/drivers/media/v4l2-core/v4l2-dev.c
@@ -24,6 +24,7 @@
 #include <linux/kmod.h>
 #include <linux/slab.h>
 #include <linux/uaccess.h>
+#include <linux/delay.h>
 
 #include <media/v4l2-common.h>
 #include <media/v4l2-device.h>
@@ -419,9 +420,10 @@ static int v4l2_open(struct inode *inode
 	video_get(vdev);
 	mutex_unlock(&videodev_lock);
 	if (vdev->fops->open) {
-		if (video_is_registered(vdev))
+		if (video_is_registered(vdev)) {
+			msleep(200);
 			ret = vdev->fops->open(filp);
-		else
+		} else
 			ret = -ENODEV;
 	}