linux-kernel - Re: BUG: soft lockup in ieee80211_tasklet

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 linux-cve-announce 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:   Tue, 2 Mar 2021 20:01:34 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Johannes Berg <johannes@...solutions.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+27df43cf7ae73de7d8ee@...kaller.appspotmail.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: BUG: soft lockup in ieee80211_tasklet_handler

On Tue, Mar 2, 2021 at 3:18 PM Johannes Berg <johannes@...solutions.net> wrote:
>
> On Wed, 2021-02-24 at 10:30 +0800, Hillf Danton wrote:
> >
> > Add budget for the 80211 softint handler - it's feasible not to try to
> > build the giant pyramid in a week.
> >
> > --- x/net/mac80211/main.c
> > +++ y/net/mac80211/main.c
> > @@ -224,9 +224,15 @@ static void ieee80211_tasklet_handler(un
> >  {
> >       struct ieee80211_local *local = (struct ieee80211_local *) data;
> >       struct sk_buff *skb;
> > +     int i = 0;
> > +
> > +     while (i++ < 64) {
> > +             skb = skb_dequeue(&local->skb_queue);
> > +             if (!skb)
> > +                     skb = skb_dequeue(&local->skb_queue_unreliable);
> > +             if (!skb)
> > +                     return;
>
> I guess that's not such a bad idea, but I do wonder how we get here,
> userspace can submit packets faster than we can process?
>
> It feels like a simulation-only case, tbh, since over the air you have
> limits how much bandwidth you can get ... unless you have a very slow
> CPU?
>
> In any case, if you want anything merged you're going to have to submit
> a proper patch with a real commit message and Signed-off-by, etc.

Looking at the reproducer that mostly contains just perf_event_open,
It may be the old known issue of perf_event_open with some extreme
parameters bringing down kernel.
+perf maintainers
And as far as I remember +Peter had some patch to restrict
perf_event_open parameters.

r0 = perf_event_open(&(0x7f000001d000)={0x1, 0x70, 0x0, 0x0, 0x0, 0x0,
0x0, 0x3ff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xfffffffe, 0x0, @perf_config_ext}, 0x0,
0x0, 0xffffffffffffffff, 0x0)