netdev - Re: [syzbot] WARNING: kmalloc bug in xdp_umem

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] [day] [month] [year] [list]

Message-ID: <CAHk-=wiRq+_jd_O1gz3J6-ANtXMY7iLpi8XFUcmtB3rBixvUXQ@mail.gmail.com>
Date:   Thu, 10 Feb 2022 10:04:27 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Björn Töpel <bjorn.topel@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Willy Tarreau <w@....eu>,
        syzbot <syzbot+11421fbbff99b989670e@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Björn Töpel <bjorn.topel@...el.com>,
        bpf <bpf@...r.kernel.org>, David Miller <davem@...emloft.net>,
        fgheet255t@...il.com, Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Martin KaFai Lau <kafai@...com>,
        KP Singh <kpsingh@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        mudongliangabcd@...il.com, Netdev <netdev@...r.kernel.org>,
        Song Liu <songliubraving@...com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Yonghong Song <yhs@...com>
Subject: Re: [syzbot] WARNING: kmalloc bug in xdp_umem_create (2)

On Thu, Feb 10, 2022 at 9:57 AM Dan Carpenter <dan.carpenter@...cle.com> wrote:
>
> Wait that would make the allocation succeed...  We don't want that.
> That was a dumb idea.  Forget I said that.

Well, sometimes that _can_ be the right model.

That said, pretty much every time this has come up, the kernel warning
has shown that yes, the code was broken and there really wasn't a
reason for doing allocations that big.

Of course, some people would be perfectly fine with the allocation
failing, they just don't want the warning. I didn't want __GFP_NOWARN
to shut it up originally because I wanted people to see all those
cases, but these days I think we can just say "yeah, people can shut
it up explicitly by saying 'go ahead and fail this allocation, don't
warn about it'".

So enough time has passed that by now I'd certainly be ok with something like

  --- a/mm/util.c
  +++ b/mm/util.c
  @@ -587,8 +587,10 @@ void *kvmalloc_node(size_t size,
                  return ret;

          /* Don't even allow crazy sizes */
  -       if (WARN_ON_ONCE(size > INT_MAX))
  +       if (unlikely(size > INT_MAX)) {
  +               WARN_ON_ONCE(!(flags & __GFP_NOWARN));
                  return NULL;
  +       }

          return __vmalloc_node(size, 1, flags, node,
                           __builtin_return_address(0));

(which is obviously COMPLETELY UNTESTED as well as being
whitespace-damaged, but you get the idea).

If somebody tests that patch and verifies it works, and writes a
little commit blurb for it, I'll apply it.

            Linus