Re: INFO: rcu detected stall in memcpy

Re: INFO: rcu detected stall in memcpy

[Dmitry Vyukov]

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.


> INFO: rcu_sched detected stalls on CPUs/tasks:
>         (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> All QSes seen, last rcu_sched kthread activity 125002
> (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> syz-executor1   R  running task    24936 11943   3739 0x0000000c
> Call Trace:
>  <IRQ>
>  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>  rcu_pending kernel/rcu/tree.c:3502 [inline]
>  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>  </IRQ>
> RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> RSP: 0000:ffff8801bd2ff868 EFLAGS: 00000212 ORIG_RAX: ffffffffffffff11
> RAX: ffff7fffffffffff RBX: ffffc9000160020b RCX: ffffffff841fceaf
> RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffffc9000160020a
> RBP: ffff8801bd2ff878 R08: ffffc9000160020a R09: dffffc0000000000
> R10: 0000000000000001 R11: ffffed0037a5ff2e R12: ffffc9000160020a
> R13: ffff8801bd2ff970 R14: dffffc0000000000 R15: ffffc9000160020a
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>  __vfs_write+0xef/0x970 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x452ac9
> RSP: 002b:00007fa354a13c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000452ac9
> RDX: 00000000fffffeb2 RSI: 0000000020083fc6 RDI: 0000000000000014
> RBP: 00000000000005b5 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6998
> R13: 00000000ffffffff R14: 00007fa354a146d4 R15: 0000000000000000
> rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> rcu_sched       R  running task    23456     8      2 0x80000000
> Call Trace:
>  context_switch kernel/sched/core.c:2799 [inline]
>  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
>  schedule+0xf5/0x430 kernel/sched/core.c:3434
>  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
>  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a113f711a23fe310561f21d1a%40google.com.
>
> For more options, visit https://groups.google.com/d/optout.

Re: INFO: rcu detected stall in memcpy

[Takashi Iwai]

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.


thanks,

Takashi

> > INFO: rcu_sched detected stalls on CPUs/tasks:
> >         (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> > All QSes seen, last rcu_sched kthread activity 125002
> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> > syz-executor1   R  running task    24936 11943   3739 0x0000000c
> > Call Trace:
> >  <IRQ>
> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> >  </IRQ>
> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> > RSP: 0000:ffff8801bd2ff868 EFLAGS: 00000212 ORIG_RAX: ffffffffffffff11
> > RAX: ffff7fffffffffff RBX: ffffc9000160020b RCX: ffffffff841fceaf
> > RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffffc9000160020a
> > RBP: ffff8801bd2ff878 R08: ffffc9000160020a R09: dffffc0000000000
> > R10: 0000000000000001 R11: ffffed0037a5ff2e R12: ffffc9000160020a
> > R13: ffff8801bd2ff970 R14: dffffc0000000000 R15: ffffc9000160020a
> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> >  memcpy include/linux/string.h:344 [inline]
> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
> >  __vfs_write+0xef/0x970 fs/read_write.c:480
> >  vfs_write+0x189/0x510 fs/read_write.c:544
> >  SYSC_write fs/read_write.c:589 [inline]
> >  SyS_write+0xef/0x220 fs/read_write.c:581
> >  entry_SYSCALL_64_fastpath+0x23/0x9a
> > RIP: 0033:0x452ac9
> > RSP: 002b:00007fa354a13c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
> > RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000452ac9
> > RDX: 00000000fffffeb2 RSI: 0000000020083fc6 RDI: 0000000000000014
> > RBP: 00000000000005b5 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6998
> > R13: 00000000ffffffff R14: 00007fa354a146d4 R15: 0000000000000000
> > rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> > rcu_sched       R  running task    23456     8      2 0x80000000
> > Call Trace:
> >  context_switch kernel/sched/core.c:2799 [inline]
> >  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
> >  schedule+0xf5/0x430 kernel/sched/core.c:3434
> >  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
> >  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
> >  kthread+0x33c/0x400 kernel/kthread.c:238
> >  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> >
> >
> > ---
> > This bug is generated by a dumb bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for details.
> > Direct all questions to syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report.
> > If you forgot to add the Reported-by tag, once the fix for this bug is
> > merged
> > into any tree, please reply to this email with:
> > #syz fix: exact-commit-title
> > To mark this as a duplicate of another syzbot report, please reply with:
> > #syz dup: exact-subject-of-another-report
> > If it's a one-off invalid bug report, please reply with:
> > #syz invalid
> > Note: if the crash happens again, it will cause creation of a new bug
> > report.
> > Note: all commands must start from beginning of the line in the email body.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "syzkaller-bugs" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to syzkaller-bugs+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/syzkaller-bugs/001a113f711a23fe310561f21d1a%40google.com.
> >
> > For more options, visit https://groups.google.com/d/optout.
> 

Re: INFO: rcu detected stall in memcpy

[Dmitry Vyukov]

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.



>> > INFO: rcu_sched detected stalls on CPUs/tasks:
>> >         (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
>> > All QSes seen, last rcu_sched kthread activity 125002
>> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
>> > syz-executor1   R  running task    24936 11943   3739 0x0000000c
>> > Call Trace:
>> >  <IRQ>
>> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
>> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>> >  </IRQ>
>> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
>> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
>> > RSP: 0000:ffff8801bd2ff868 EFLAGS: 00000212 ORIG_RAX: ffffffffffffff11
>> > RAX: ffff7fffffffffff RBX: ffffc9000160020b RCX: ffffffff841fceaf
>> > RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffffc9000160020a
>> > RBP: ffff8801bd2ff878 R08: ffffc9000160020a R09: dffffc0000000000
>> > R10: 0000000000000001 R11: ffffed0037a5ff2e R12: ffffc9000160020a
>> > R13: ffff8801bd2ff970 R14: dffffc0000000000 R15: ffffc9000160020a
>> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>> >  memcpy include/linux/string.h:344 [inline]
>> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>> >  __vfs_write+0xef/0x970 fs/read_write.c:480
>> >  vfs_write+0x189/0x510 fs/read_write.c:544
>> >  SYSC_write fs/read_write.c:589 [inline]
>> >  SyS_write+0xef/0x220 fs/read_write.c:581
>> >  entry_SYSCALL_64_fastpath+0x23/0x9a
>> > RIP: 0033:0x452ac9
>> > RSP: 002b:00007fa354a13c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000001
>> > RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000452ac9
>> > RDX: 00000000fffffeb2 RSI: 0000000020083fc6 RDI: 0000000000000014
>> > RBP: 00000000000005b5 R08: 0000000000000000 R09: 0000000000000000
>> > R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6998
>> > R13: 00000000ffffffff R14: 00007fa354a146d4 R15: 0000000000000000
>> > rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
>> > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
>> > rcu_sched       R  running task    23456     8      2 0x80000000
>> > Call Trace:
>> >  context_switch kernel/sched/core.c:2799 [inline]
>> >  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
>> >  schedule+0xf5/0x430 kernel/sched/core.c:3434
>> >  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
>> >  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
>> >  kthread+0x33c/0x400 kernel/kthread.c:238
>> >  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>> >
>> >
>> > ---
>> > This bug is generated by a dumb bot. It may contain errors.
>> > See https://goo.gl/tpsmEJ for details.
>> > Direct all questions to syzkaller@googlegroups.com.
>> >
>> > syzbot will keep track of this bug report.
>> > If you forgot to add the Reported-by tag, once the fix for this bug is
>> > merged
>> > into any tree, please reply to this email with:
>> > #syz fix: exact-commit-title
>> > To mark this as a duplicate of another syzbot report, please reply with:
>> > #syz dup: exact-subject-of-another-report
>> > If it's a one-off invalid bug report, please reply with:
>> > #syz invalid
>> > Note: if the crash happens again, it will cause creation of a new bug
>> > report.
>> > Note: all commands must start from beginning of the line in the email body.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "syzkaller-bugs" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an
>> > email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/syzkaller-bugs/001a113f711a23fe310561f21d1a%40google.com.
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>

Re: INFO: rcu detected stall in memcpy

[Takashi Iwai]

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.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

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?

In anyway, they are obvious bugs to be fixed, so I'm going to queue to
my tree.


thanks,

Takashi


[-- Attachment #2: 0001-ALSA-pcm-Add-missing-error-checks-in-OSS-emulation-p.patch --]
[-- Type: application/octet-stream, Size: 1676 bytes --]

>From 6708913750344a900f2e73bfe4a4d6dbbce4fe8d Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Thu, 4 Jan 2018 16:39:27 +0100
Subject: [PATCH 1/2] ALSA: pcm: Add missing error checks in OSS emulation
 plugin builder

In the OSS emulation plugin builder where the frame size is parsed in
the plugin chain, some places miss the possible errors returned from
the plugin src_ or dst_frames callback.

This patch papers over such places.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/oss/pcm_plugin.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/sound/core/oss/pcm_plugin.c b/sound/core/oss/pcm_plugin.c
index cadc93792868..85a56af104bd 100644
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -592,18 +592,26 @@ snd_pcm_sframes_t snd_pcm_plug_write_transfer(struct snd_pcm_substream *plug, st
 	snd_pcm_sframes_t frames = size;
 
 	plugin = snd_pcm_plug_first(plug);
-	while (plugin && frames > 0) {
+	while (plugin) {
+		if (frames <= 0)
+			return frames;
 		if ((next = plugin->next) != NULL) {
 			snd_pcm_sframes_t frames1 = frames;
-			if (plugin->dst_frames)
+			if (plugin->dst_frames) {
 				frames1 = plugin->dst_frames(plugin, frames);
+				if (frames1 <= 0)
+					return frames1;
+			}
 			if ((err = next->client_channels(next, frames1, &dst_channels)) < 0) {
 				return err;
 			}
 			if (err != frames1) {
 				frames = err;
-				if (plugin->src_frames)
+				if (plugin->src_frames) {
 					frames = plugin->src_frames(plugin, frames1);
+					if (frames <= 0)
+						return frames;
+				}
 			}
 		} else
 			dst_channels = NULL;
-- 
2.15.1


[-- Attachment #3: 0002-ALSA-aloop-Fix-racy-hw-constraints-adjustment.patch --]
[-- Type: application/octet-stream, Size: 5748 bytes --]

>From ba043d316c911c80ec067bccff4e76e7c11619d3 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Thu, 4 Jan 2018 17:38:54 +0100
Subject: [PATCH 2/2] ALSA: aloop: Fix racy hw constraints adjustment

The aloop driver tries to update the hw constraints of the connected
target on the cable of the opened PCM substream.  This is done by
adding the extra hw constraints rules referring to the substream
runtime->hw fields, while the other substream may update the runtime
hw of another side on the fly.

This is, however, racy and may result in the inconsistent values when
both PCM streams perform the prepare concurrently.  One of the reason
is that it overwrites the other's runtime->hw field; which is not only
racy but also broken when it's called before the open of another side
finishes.  And, since the reference to runtime->hw isn't protected,
the concurrent write may give the partial value update and become
inconsistent.

This patch is an attempt to fix and clean up:
- The prepare doesn't change the runtime->hw of other side any longer,
  but only update the cable->hw that is referred commonly.
- The extra rules refer to the loopback_pcm object instead of the
  runtime->hw.  The actual hw is deduced from cable->hw.
- The extra rules take the cable_lock to protect against the race.

Fixes: b1c73fc8e697 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/drivers/aloop.c | 51 +++++++++++++++++++++------------------------------
 1 file changed, 21 insertions(+), 30 deletions(-)

diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
index afac886ffa28..b1eee1a1e925 100644
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -305,19 +305,6 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd)
 	return 0;
 }
 
-static void params_change_substream(struct loopback_pcm *dpcm,
-				    struct snd_pcm_runtime *runtime)
-{
-	struct snd_pcm_runtime *dst_runtime;
-
-	if (dpcm == NULL || dpcm->substream == NULL)
-		return;
-	dst_runtime = dpcm->substream->runtime;
-	if (dst_runtime == NULL)
-		return;
-	dst_runtime->hw = dpcm->cable->hw;
-}
-
 static void params_change(struct snd_pcm_substream *substream)
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
@@ -329,10 +316,6 @@ static void params_change(struct snd_pcm_substream *substream)
 	cable->hw.rate_max = runtime->rate;
 	cable->hw.channels_min = runtime->channels;
 	cable->hw.channels_max = runtime->channels;
-	params_change_substream(cable->streams[SNDRV_PCM_STREAM_PLAYBACK],
-				runtime);
-	params_change_substream(cable->streams[SNDRV_PCM_STREAM_CAPTURE],
-				runtime);
 }
 
 static int loopback_prepare(struct snd_pcm_substream *substream)
@@ -620,12 +603,14 @@ static unsigned int get_cable_index(struct snd_pcm_substream *substream)
 static int rule_format(struct snd_pcm_hw_params *params,
 		       struct snd_pcm_hw_rule *rule)
 {
-
-	struct snd_pcm_hardware *hw = rule->private;
+	struct loopback_pcm *dpcm = rule->private;
+	struct loopback_cable *cable = dpcm->cable;
 	struct snd_mask *maskp = hw_param_mask(params, rule->var);
 
-	maskp->bits[0] &= (u_int32_t)hw->formats;
-	maskp->bits[1] &= (u_int32_t)(hw->formats >> 32);
+	mutex_lock(&dpcm->loopback->cable_lock);
+	maskp->bits[0] &= (u_int32_t)cable->hw.formats;
+	maskp->bits[1] &= (u_int32_t)(cable->hw.formats >> 32);
+	mutex_unlock(&dpcm->loopback->cable_lock);
 	memset(maskp->bits + 2, 0, (SNDRV_MASK_MAX-64) / 8); /* clear rest */
 	if (! maskp->bits[0] && ! maskp->bits[1])
 		return -EINVAL;
@@ -635,11 +620,14 @@ static int rule_format(struct snd_pcm_hw_params *params,
 static int rule_rate(struct snd_pcm_hw_params *params,
 		     struct snd_pcm_hw_rule *rule)
 {
-	struct snd_pcm_hardware *hw = rule->private;
+	struct loopback_pcm *dpcm = rule->private;
+	struct loopback_cable *cable = dpcm->cable;
 	struct snd_interval t;
 
-        t.min = hw->rate_min;
-        t.max = hw->rate_max;
+	mutex_lock(&dpcm->loopback->cable_lock);
+	t.min = cable->hw.rate_min;
+	t.max = cable->hw.rate_max;
+	mutex_unlock(&dpcm->loopback->cable_lock);
         t.openmin = t.openmax = 0;
         t.integer = 0;
 	return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -648,11 +636,14 @@ static int rule_rate(struct snd_pcm_hw_params *params,
 static int rule_channels(struct snd_pcm_hw_params *params,
 			 struct snd_pcm_hw_rule *rule)
 {
-	struct snd_pcm_hardware *hw = rule->private;
+	struct loopback_pcm *dpcm = rule->private;
+	struct loopback_cable *cable = dpcm->cable;
 	struct snd_interval t;
 
-        t.min = hw->channels_min;
-        t.max = hw->channels_max;
+	mutex_lock(&dpcm->loopback->cable_lock);
+	t.min = cable->hw.channels_min;
+	t.max = cable->hw.channels_max;
+	mutex_unlock(&dpcm->loopback->cable_lock);
         t.openmin = t.openmax = 0;
         t.integer = 0;
 	return snd_interval_refine(hw_param_interval(params, rule->var), &t);
@@ -699,19 +690,19 @@ static int loopback_open(struct snd_pcm_substream *substream)
 	/* are cached -> they do not reflect the actual state */
 	err = snd_pcm_hw_rule_add(runtime, 0,
 				  SNDRV_PCM_HW_PARAM_FORMAT,
-				  rule_format, &runtime->hw,
+				  rule_format, dpcm,
 				  SNDRV_PCM_HW_PARAM_FORMAT, -1);
 	if (err < 0)
 		goto unlock;
 	err = snd_pcm_hw_rule_add(runtime, 0,
 				  SNDRV_PCM_HW_PARAM_RATE,
-				  rule_rate, &runtime->hw,
+				  rule_rate, dpcm,
 				  SNDRV_PCM_HW_PARAM_RATE, -1);
 	if (err < 0)
 		goto unlock;
 	err = snd_pcm_hw_rule_add(runtime, 0,
 				  SNDRV_PCM_HW_PARAM_CHANNELS,
-				  rule_channels, &runtime->hw,
+				  rule_channels, dpcm,
 				  SNDRV_PCM_HW_PARAM_CHANNELS, -1);
 	if (err < 0)
 		goto unlock;
-- 
2.15.1

Re: INFO: rcu detected stall in memcpy

[Dmitry Vyukov]

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.

Re: INFO: rcu detected stall in memcpy

[Takashi Iwai]

On Sun, 07 Jan 2018 12:30:53 +0100,
Dmitry Vyukov wrote:
> 
> 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

OK, noted.

> > 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

Ah, I didn't know that each bot can test patches individually.

> 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.

Yes, I could test and find the culprit with the given reproducer.

> 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.

Some have been already tagged with reported-by.  Some are mostly
irrelevant but casually found during the debug session for the bugs
syzkaller spotted.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

[Dmitry Vyukov]

On Mon, Jan 8, 2018 at 2:15 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Sun, 07 Jan 2018 12:30:53 +0100,
> Dmitry Vyukov wrote:
>>
>> 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
>
> OK, noted.
>
>> > 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
>
> Ah, I didn't know that each bot can test patches individually.
>
>> 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.
>
> Yes, I could test and find the culprit with the given reproducer.
>
>> 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.
>
> Some have been already tagged with reported-by.  Some are mostly
> irrelevant but casually found during the debug session for the bugs
> syzkaller spotted.


I think this is fixed with:

#syz fix: ALSA: pcm: Abort properly at pending signal in OSS read/write loops