Re: WARNING in snd_usb_motu_microbookii_communicate/usb_submit_urb
From: Takashi Iwai
Date: Wed Jul 24 2019 - 09:45:45 EST
On Wed, 24 Jul 2019 15:33:21 +0200,
Andrey Konovalov wrote:
> On Wed, Jul 24, 2019 at 3:15 PM Takashi Iwai <tiwai@xxxxxxx> wrote:
> > On Tue, 23 Jul 2019 19:03:29 +0200,
> > Andrey Konovalov wrote:
> > >
> > > (Takashi, with your helper check syzkaller now generates a new bug
> > > report (not reported by syzbot yet due to breakage during kernel boot
> > > on 5.3-rc1, so see below) and I guess this has to do with a missing ep
> > > != NULL check).
> > >
> > > kasan: CONFIG_KASAN_INLINE enabled
> > > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > > general protection fault: 0000 [#1] SMP KASAN
> > > CPU: 1 PID: 74 Comm: kworker/1:1 Not tainted 5.3.0-rc1+ #40
> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
> > > Workqueue: usb_hub_wq hub_event
> > > RIP: 0010:snd_usb_pipe_sanity_check+0x80/0x130 sound/usb/helper.c:75
> > > Code: 48 c1 ea 03 80 3c 02 00 0f 85 b3 00 00 00 48 8b 6d 00 c1 eb 1e
> > > 48 b8 00 00 00 00 00 fc ff df 48 8d 7d 03 48 89 fa 48 c1 ea 03 <0f> b6
> > > 04 02 48 89 fa 83 e2 07 38 d0 7f 04 84 c0 75 7b 48 b8 00 00
> > > RSP: 0018:ffff88806c33f0a8 EFLAGS: 00010246
> > > RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff833819c2
> > > RDX: 0000000000000000 RSI: ffffffff833819dc RDI: 0000000000000003
> > > RBP: 0000000000000000 R08: ffff88806c330000 R09: fffffbfff0d1a792
> > > R10: fffffbfff0d1a791 R11: ffffffff868d3c8f R12: 0000000000000000
> > > R13: dffffc0000000000 R14: ffff88806975cc80 R15: ffff88806975c4a0
> > > FS: 0000000000000000(0000) GS:ffff88806d100000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00007fcc3a48c000 CR3: 000000006861c003 CR4: 0000000000160ee0
> > > Call Trace:
> > > snd_usb_accessmusic_boot_quirk sound/usb/quirks.c:835 [inline]
> > > snd_usb_apply_boot_quirk+0xa19/0xc60 sound/usb/quirks.c:1267
> > > usb_audio_probe+0x2ec/0x1f40 sound/usb/card.c:576
> > (snip)
> > So it's a NULL pointer returned from usb_pipe_endpoint() with an
> > invalid pipe. The fix patch is attached below.
> Thanks for the fix! Do you think it makes sense to reuse the already
> existing usb_urb_ep_type_check() function instead of
> snd_usb_pipe_sanity_check() as Hillf suggested? They seem to be doing
> essentially the same thing.
Ah yes, that makes sense. I don't mind either way.
If Hillf can submit a fix patch quickly, that's better.
I decided to have a small own helper for the ease of backporting,
possibly to stable trees later on. Other than that, a common helper
is a better choice.