On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai tiwai@suse.de wrote:
On Thu, 04 Jan 2018 15:17:23 +0100, Takashi Iwai wrote:
On Thu, 04 Jan 2018 15:01:06 +0100, Dmitry Vyukov wrote:
On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai tiwai@suse.de wrote:
On Thu, 04 Jan 2018 13:08:45 +0100, Dmitry Vyukov wrote:
On Thu, Jan 4, 2018 at 1:03 PM, syzbot syzbot+387f48da65cb522abfe8@syzkaller.appspotmail.com wrote:
Hello,
syzkaller hit the following crash on 30a7acd573899fd8b8ac39236eff6468b195ac7d git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. Unfortunately, I don't have any reproducer for this bug yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+387f48da65cb522abfe8@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer.
This looks ALSA-related. +ALSA maintainers.
Not sure exactly what triggers it. It's the simple memcpy(), and I don't know where RCU is involved in that code path.
BTW, other two suspicious RCU usage reports are actually stopped at the second WARN_ON() after the RCU message, and the second WARN_ON() is independent from RCU; it's the known spurious WARN_ON() and was already removed in the sound git tree.
Hi Takashi,
Another similar one just popped up:
https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
This looks like mulaw_decode enters an infinite loop, or at least doing very large amount of computations without a resched, e.g. (uint64_t)-1 number of iterations of something along these lines.
OK, that makes sense.
My rough guess is that it's the misconfigured aloop device by concurrent setup. The aloop device allows to restrict the parameters of the other side of the connection, and something bad may happen there if both sides are updated concurrently.
We've seen segfault by memset() at loopback_preapre() in sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which indicates also the wrongly setup parameters that overflows the allocated buffer.
Below two patches may possibly plug the holes, but I'm not entirely sure whether that's the exact culprit. Could you put them into syzbot to watch whether they have any influence?
Hi Takashi,
I've gave an answer to this here: https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ
In anyway, they are obvious bugs to be fixed, so I'm going to queue to my tree.
The options are: 1. You can ask syzbot to test the patch separately. This requires a reproducer, but there is this bug which has a reproducer and seems to have the same root cause: https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ 2. You can reproduce it with the reproducer from here: https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ and then test the patch as extensively as needed. 3. If you have some confidence that the patch fixes the problem, then mark the commit with the tag: Reported-by: syzbot+387f48da65cb522abfe8@syzkaller.appspotmail.com then syzbot will notify if this still happens after the commit reaches tested trees.