[alsa-devel] BUG: unable to handle kernel paging request in snd_seq_oss_readq_puts

[Takashi Iwai]

On Mon, 20 Nov 2017 13:47:28 +0100,
Dmitry Vyukov wrote:
> 
> On Wed, Nov 1, 2017 at 8:49 PM, Takashi Iwai <tiwai at suse.de> wrote:
> > On Wed, 01 Nov 2017 19:39:46 +0100,
> > Dmitry Vyukov wrote:
> >>
> >> On Wed, Nov 1, 2017 at 9:38 PM, syzbot
> >> <bot+31681772ec7a18dde8d3f8caf475f361a89b9514 at syzkaller.appspotmail.com>
> >> wrote:
> >> > Hello,
> >> >
> >> > syzkaller hit the following crash on
> >> > fc2e8b1a47c14b22c33eb087fca0db58e1f4ed0e
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> >> > compiler: gcc (GCC) 7.1.1 20170620
> >> > .config is attached
> >> > Raw console output is attached.
> >> > C reproducer is attached
> >> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> >> > for information about syzkaller reproducers
> >>
> >> This also happened on more recent commits, including upstream
> >> 9c323bff13f92832e03657cabdd70d731408d621 (Oct 20):
> >
> > Could you try the patch below with CONFIG_SND_DEBUG=y and see whether
> > it catches any bad calls?  It's already in for-next branch for 4.15.
> 
> 
> Hi Takashi,
> 
> Unfortunately it's not possible to test custom patches in syzbot infrastructure.
> We've experimented with applying a bunch of custom patches in the past
> and it lead to unrecoverable mess. We were not able to communicate
> precise state of code with reports, we were not able to provide
> meaningful report with line numbers that matter (not possible to
> understand what exactly line caused a bug), developers could
> (rightfully) suspect that some bugs might be caused the unknown set of
> private patches, random subset of patches won't apply and that set
> changes over time and depends on order in which we apply patches, etc.
> It's also not possible to dedicate a syzkaller instance with a bunch
> of attached machines for this. First, it will require lots of
> resources (your request is not unique). Then, whenever we test kernel
> we get dozens of bugs. What should we do with these bugs? We don't
> know which are related to your patch and which are not. We can't
> report them upstream (see above). Basically you would need to go
> through these dozens of bugs after testing and do something with each
> of them, but I don't think you want to.
> 
> But we are happy to test whatever is in upstream tree (this patch already is).

The bug turned out to be a different issue as the suggested patch may
fix, and I believe we already address it by the upstream commit
132d358b183ac6ad8b3fea32ad5e0663456d18d1
    ALSA: seq: Fix OSS sysex delivery in OSS emulation

I thought I submitted the fix line, but it might be to another syzbot
report or I did wrong.


> Re CONFIG_SND_DEBUG=y, should we enable it permanently in syzbot configs?

Yes, it's worth to have CONFIG_SND_DEBUG=y in fuzzer.

> From our point of view, the more debug configs are enabled, the more
> bugs we find, the better. There just must be somebody who will then
> fix problems uncovered by the config (either bugs of config false
> positives).

In the case of CONFIG_SND_DEBUG, it gives more debug hints by adding
WARN_ON(), but the code behavior is almost same.

> If you will take a look on the config attached to the first mail, do
> you see anything else to fix there re sound? Maybe turn off some
> deprecated configs that nobody uses for a long time? Or enable some
> new configs?

CONFIG_SND_DYNAMIC_MINORS=y is recommended for modern systems, too.

Thanks!


Takashi