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  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:   Sat, 28 Dec 2019 12:15:48 +0100
From:   Florian Westphal <fw@...len.de>
To:     syzbot <syzbot+dc9071cc5a85950bdfce@...kaller.appspotmail.com>
Cc:     davem@...emloft.net, jhs@...atatu.com, jiri@...nulli.us,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, xiyou.wangcong@...il.com,
        eric.dumazet@...il.com
Subject: Re: INFO: rcu detected stall in br_handle_frame (2)

syzbot <syzbot+dc9071cc5a85950bdfce@...kaller.appspotmail.com> wrote:

[ CC Eric, fq related ]

> syzbot found the following crash on:
> 
> HEAD commit:    7e0165b2 Merge branch 'akpm' (patches from Andrew)
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=116ec09ee00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1b59a3066828ac4c
> dashboard link: https://syzkaller.appspot.com/bug?extid=dc9071cc5a85950bdfce
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=159182c1e00000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1221218ee00000
> 
> Bisection is inconclusive: the bug happens on the oldest tested release.
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=158224c1e00000
> final crash:    https://syzkaller.appspot.com/x/report.txt?x=178224c1e00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=138224c1e00000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+dc9071cc5a85950bdfce@...kaller.appspotmail.com
> 
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> 	(detected by 0, t=10502 jiffies, g=10149, q=201)
> rcu: All QSes seen, last rcu_preempt kthread activity 10502
> (4294978441-4294967939), jiffies_till_next_fqs=1, root ->qsmask 0x0
> sshd            R  running task    26584 10034   9965 0x00000008
> Call Trace:
>  <IRQ>
>  sched_show_task kernel/sched/core.c:5954 [inline]
[..]

The reproducer sets up 'fq' sched with TCA_FQ_QUANTUM == 0x80000000

This causes infinite loop in fq_dequeue:

if (f->credit <= 0) {
  f->credit += q->quantum;
  goto begin;
}

... because f->credit is either 0 or -2147483648.

Eric, what is a 'sane' ->quantum value?

One could simply add a 'quantum > 0 && quantum < INT_MAX'
constraint afaics.

If you don't have a better idea/suggestion for an upperlimit INT_MAX
would be enough to prevent perpetual <= 0 condition.

Powered by blists - more mailing lists