Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <acdf065c-256d-47b0-5c20-203ff4b213d6@gmail.com> <CAHk-=wiENdk_AXGRrmbbOYqq9zYptdv=vYszgG2ZzztDUTJwRA@mail.gmail.com>
In-Reply-To: <CAHk-=wiENdk_AXGRrmbbOYqq9zYptdv=vYszgG2ZzztDUTJwRA@mail.gmail.com>
From:   Eric Dumazet <edumazet@google.com>
Date:   Fri, 3 Sep 2021 16:00:20 -0700
Message-ID: <CANn89iJ5Q-PeZ=+87DT-BY4EVhWZATtieid59W7Tq0bkCvRQbw@mail.gmail.com>
Subject: Re: dozens of sysbot reports
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Eric Dumazet <eric.dumazet@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 3, 2021 at 3:21 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Sep 3, 2021 at 1:44 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I have a pile of (still under triage) sysbot reports coming after one of your patch
> >
> > Typical stack trace:
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 24889 at mm/util.c:597 kvmalloc_node+0x111/0x120 mm/util.c:597
> > Call Trace:
> >  hash_ipport_create+0x3dd/0x1220 net/netfilter/ipset/ip_set_hash_gen.h:1524
> >  ip_set_create+0x782/0x15a0 net/netfilter/ipset/ip_set_core.c:1100
> >  nfnetlink_rcv_msg+0xbc9/0x13f0 net/netfilter/nfnetlink.c:296
>
> So the real question is mainly just whether those huge allocations
> actually make sense or not.
>
> If they truly are sensible, we can remove the warning. But it would be
> good to perhaps look at them more.
>
> Because no:
>
> > Do we want to fix all problematic callers, with ad-hoc patches like
>
> Not insane patches like this, no.
>
> >  ip_set_alloc(size_t size)
> >  {
> > +       if (size > INT_MAX)
> > +               return NULL;
> >         return kvzalloc(size, GFP_KERNEL_ACCOUNT);
> >  }
>
> But does that kind of size really make sense? I'm looking at the
> particular caller, is it *really* senseible to have a 4GB+ hash table
> size?
>
> IOW, I don't think we want that warning to cause the above kinds of
> ad-hoc patches.
>
> But I _do_ want that warning to make people go "is that allocation
> truly sensible"?
>
> IOW, it sounds like you can send some netlink message that causes
> insane hash size allocations. Shouldn't _that_ be fixed?
>

Probably, but as I said there are many different reports.

If there was only one or two, I would simply have sent a fix(es).

I will probably release these bugs, so that they can be spread among
interested parties.

 WARNING: CPU: 1 PID: 26011 at mm/util.c:597 kvmalloc_node+0x111/0x120
mm/util.c:597
Modules linked in:
CPU: 1 PID: 26011 Comm: syz-executor.2 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
RIP: 0010:kvmalloc_node+0x111/0x120 mm/util.c:597
Code: 01 00 00 00 4c 89 e7 e8 8d 12 0d 00 49 89 c5 e9 69 ff ff ff e8
f0 21 d1 ff 41 89 ed 41 81 cd 00 20 01 00 eb 95 e8 df 21 d1 ff <0f> 0b
e9 4c ff ff ff 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 e8 c6
RSP: 0018:ffffc90003a77720 EFLAGS: 00010216
RAX: 0000000000000e48 RBX: ffffc90003a77e18 RCX: ffffc9000df6d000
RDX: 0000000000040000 RSI: ffffffff81a4f621 RDI: 0000000000000003
RBP: 0000000000002dc0 R08: 000000007fffffff R09: 00000000ffffffff
R10: ffffffff81a4f5de R11: 0000000000000000 R12: 000000020008a100
R13: 0000000000000000 R14: 00000000ffffffff R15: ffff88802032c000
FS:  00007fbfc5618700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000540198 CR3: 000000006e529000 CR4: 0000000000350ee0
Call Trace:
 kvmalloc include/linux/mm.h:806 [inline]
 kvmalloc_array include/linux/mm.h:824 [inline]
 kvcalloc include/linux/mm.h:829 [inline]
 check_btf_line+0x1a9/0xad0 kernel/bpf/verifier.c:9925
 check_btf_info kernel/bpf/verifier.c:10049 [inline]
 bpf_check+0x1636/0xbd20 kernel/bpf/verifier.c:13759
 bpf_prog_load+0xe57/0x21f0 kernel/bpf/syscall.c:2301
 __sys_bpf+0x67e/0x5df0 kernel/bpf/syscall.c:4587
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80