* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 19:47 ` Alan Stern
@ 2019-12-10 19:48 ` syzbot
2019-12-10 20:17 ` Alan Stern
2019-12-10 19:48 ` Re: KASAN: use-after-free Read in usbvision_v4l2_open syzbot
2019-12-10 20:06 ` Andrey Konovalov
2 siblings, 1 reply; 15+ messages in thread
From: syzbot @ 2019-12-10 19:48 UTC (permalink / raw)
To: Alan Stern
Cc: andreyknvl, hverkuil, jrdr.linux, linux-kernel, linux-media,
linux-usb, mchehab, rfontana, stern, syzkaller-bugs, tglx
> 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;
> }
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 19:48 ` syzbot
@ 2019-12-10 20:17 ` Alan Stern
2019-12-11 14:23 ` Andrey Konovalov
2019-12-12 16:52 ` general protection fault in usb_set_interface Alan Stern
0 siblings, 2 replies; 15+ messages in thread
From: Alan Stern @ 2019-12-10 20:17 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, hverkuil, jrdr.linux, Kernel development list,
linux-media, USB list, mchehab, rfontana, syzkaller-bugs, tglx
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;
}
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 20:17 ` Alan Stern
@ 2019-12-11 14:23 ` Andrey Konovalov
2019-12-11 15:14 ` Alan Stern
2019-12-12 16:52 ` general protection fault in usb_set_interface Alan Stern
1 sibling, 1 reply; 15+ messages in thread
From: Andrey Konovalov @ 2019-12-11 14:23 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, Hans Verkuil, Souptick Joarder, Kernel development list,
linux-media, USB list, Mauro Carvalho Chehab, Richard Fontana,
syzkaller-bugs, Thomas Gleixner
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;
> }
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-11 14:23 ` Andrey Konovalov
@ 2019-12-11 15:14 ` Alan Stern
2019-12-11 15:35 ` Dmitry Vyukov
0 siblings, 1 reply; 15+ messages in thread
From: Alan Stern @ 2019-12-11 15:14 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzbot, Hans Verkuil, Souptick Joarder, Kernel development list,
linux-media, USB list, Mauro Carvalho Chehab, Richard Fontana,
syzkaller-bugs, Thomas Gleixner
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-11 15:14 ` Alan Stern
@ 2019-12-11 15:35 ` Dmitry Vyukov
0 siblings, 0 replies; 15+ messages in thread
From: Dmitry Vyukov @ 2019-12-11 15:35 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Konovalov, syzbot, Hans Verkuil, Souptick Joarder,
Kernel development list, linux-media, USB list,
Mauro Carvalho Chehab, Richard Fontana, syzkaller-bugs,
Thomas Gleixner
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: general protection fault in usb_set_interface
2019-12-10 20:17 ` Alan Stern
2019-12-11 14:23 ` Andrey Konovalov
@ 2019-12-12 16:52 ` Alan Stern
1 sibling, 0 replies; 15+ messages in thread
From: Alan Stern @ 2019-12-12 16:52 UTC (permalink / raw)
To: syzbot
Cc: andreyknvl, hverkuil, jrdr.linux, Kernel development list,
linux-media, USB list, mchehab, rfontana
[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;
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 19:47 ` Alan Stern
2019-12-10 19:48 ` syzbot
@ 2019-12-10 19:48 ` syzbot
2019-12-10 20:06 ` Andrey Konovalov
2 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2019-12-10 19:48 UTC (permalink / raw)
To: Alan Stern
Cc: andreyknvl, hverkuil, jrdr.linux, linux-kernel, linux-media,
linux-usb, mchehab, rfontana, stern, syzkaller-bugs, tglx
> 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;
> }
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 19:47 ` Alan Stern
2019-12-10 19:48 ` syzbot
2019-12-10 19:48 ` Re: KASAN: use-after-free Read in usbvision_v4l2_open syzbot
@ 2019-12-10 20:06 ` Andrey Konovalov
2019-12-10 20:13 ` Alan Stern
2 siblings, 1 reply; 15+ messages in thread
From: Andrey Konovalov @ 2019-12-10 20:06 UTC (permalink / raw)
To: Alan Stern
Cc: syzbot, Hans Verkuil, Souptick Joarder, LKML, linux-media,
USB list, Mauro Carvalho Chehab, Richard Fontana, syzkaller-bugs,
Thomas Gleixner
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;
> }
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 20:06 ` Andrey Konovalov
@ 2019-12-10 20:13 ` Alan Stern
2019-12-11 14:22 ` Andrey Konovalov
0 siblings, 1 reply; 15+ messages in thread
From: Alan Stern @ 2019-12-10 20:13 UTC (permalink / raw)
To: Andrey Konovalov
Cc: syzbot, Hans Verkuil, Souptick Joarder, LKML, linux-media,
USB list, Mauro Carvalho Chehab, Richard Fontana, syzkaller-bugs,
Thomas Gleixner
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-10 20:13 ` Alan Stern
@ 2019-12-11 14:22 ` Andrey Konovalov
2019-12-11 15:30 ` Dmitry Vyukov
0 siblings, 1 reply; 15+ messages in thread
From: Andrey Konovalov @ 2019-12-11 14:22 UTC (permalink / raw)
To: Alan Stern, Dmitry Vyukov
Cc: syzbot, Hans Verkuil, Souptick Joarder, LKML, linux-media,
USB list, Mauro Carvalho Chehab, Richard Fontana, syzkaller-bugs,
Thomas Gleixner
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-11 14:22 ` Andrey Konovalov
@ 2019-12-11 15:30 ` Dmitry Vyukov
2019-12-11 16:22 ` Alan Stern
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Vyukov @ 2019-12-11 15:30 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Alan Stern, syzbot, Hans Verkuil, Souptick Joarder, LKML,
linux-media, USB list, Mauro Carvalho Chehab, Richard Fontana,
syzkaller-bugs, Thomas Gleixner
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-11 15:30 ` Dmitry Vyukov
@ 2019-12-11 16:22 ` Alan Stern
2019-12-12 16:08 ` Andrey Konovalov
0 siblings, 1 reply; 15+ messages in thread
From: Alan Stern @ 2019-12-11 16:22 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andrey Konovalov, syzbot, Hans Verkuil, Souptick Joarder, LKML,
linux-media, USB list, Mauro Carvalho Chehab, Richard Fontana,
syzkaller-bugs, Thomas Gleixner
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: KASAN: use-after-free Read in usbvision_v4l2_open
2019-12-11 16:22 ` Alan Stern
@ 2019-12-12 16:08 ` Andrey Konovalov
0 siblings, 0 replies; 15+ messages in thread
From: Andrey Konovalov @ 2019-12-12 16:08 UTC (permalink / raw)
To: Alan Stern
Cc: Dmitry Vyukov, syzbot, Hans Verkuil, Souptick Joarder, LKML,
linux-media, USB list, Mauro Carvalho Chehab, Richard Fontana,
syzkaller-bugs, Thomas Gleixner
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?
^ permalink raw reply [flat|nested] 15+ messages in thread