linux-kernel - Re: [syzbot] [usb?] [media?] possible deadlock in vb2_video_unregister

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Feb 2024 13:49:30 +0900
From: Tomasz Figa <tfiga@...omium.org>
To: Benjamin Gaignard <benjamin.gaignard@...labora.com>
Cc: syzbot <syzbot+3b1d4b3d5f7a358bf9a9@...kaller.appspotmail.com>, hdanton@...a.com, 
	hverkuil-cisco@...all.nl, hverkuil@...all.nl, 
	laurent.pinchart@...asonboard.com, linux-kernel@...r.kernel.org, 
	linux-media@...r.kernel.org, linux-usb@...r.kernel.org, 
	m.szyprowski@...sung.com, mchehab@...nel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] [media?] possible deadlock in vb2_video_unregister_device

On Tue, Feb 20, 2024 at 12:49 AM Benjamin Gaignard
<benjamin.gaignard@...labora.com> wrote:
>
>
> Le 19/02/2024 à 14:10, syzbot a écrit :
> > syzbot has bisected this issue to:
> >
> > commit c838530d230bc638d79b78737fc4488ffc28c1ee
> > Author: Benjamin Gaignard <benjamin.gaignard@...labora.com>
> > Date:   Thu Nov 9 16:34:59 2023 +0000
> >
> >      media: media videobuf2: Be more flexible on the number of queue stored buffers
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
> > start commit:   b401b621758e Linux 6.8-rc5
> > git tree:       upstream
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=156dc872180000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=116dc872180000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=eff9f3183d0a20dd
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3b1d4b3d5f7a358bf9a9
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13ffaae8180000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13ef909c180000
> >
> > Reported-by: syzbot+3b1d4b3d5f7a358bf9a9@...kaller.appspotmail.com
> > Fixes: c838530d230b ("media: media videobuf2: Be more flexible on the number of queue stored buffers")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> Hans,
> I think the issue occur because of this part of the commit:
> @@ -1264,7 +1264,7 @@ void vb2_video_unregister_device(struct video_device *vdev)
>           */
>          get_device(&vdev->dev);
>          video_unregister_device(vdev);
> -       if (vdev->queue && vdev->queue->owner) {
> +       if (vdev->queue) {
>                  struct mutex *lock = vdev->queue->lock ?
>                          vdev->queue->lock : vdev->lock;
>
> but I wonder if the correction shouldn't be to remove usbtv->vb2q_lock mutex in usbtv_video_free().
>
> Any opinion ?

That is probably what triggered the failure detected by syzbot, but I
don't think we've ever had a guarantee that owner is NULL in that
code.

Looking at the uvc driver [1], it doesn't seem to need any special
locking there (after all the vb2 code acquires them).  (It also
doesn't have the custom clean-up code that the usbtv driver has in
usbtv_stop(), but that's another story). So maybe all we need to fix
it is removing the mutex_lock/unlock() calls?

[1] https://elixir.bootlin.com/linux/v6.8-rc4/source/drivers/media/usb/uvc/uvc_driver.c#L1906

Best,
Tomasz