From: Willy Tarreau <w@1wt.eu>
To: syzbot <syzbot+11421fbbff99b989670e@syzkaller.appspotmail.com>
Cc: akpm@linux-foundation.org, andrii@kernel.org, ast@kernel.org,
bjorn.topel@gmail.com, bjorn.topel@intel.com, bjorn@kernel.org,
bpf@vger.kernel.org, daniel@iogearbox.net, davem@davemloft.net,
fgheet255t@gmail.com, hawk@kernel.org, john.fastabend@gmail.com,
jonathan.lemon@gmail.com, kafai@fb.com, kpsingh@kernel.org,
kuba@kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, magnus.karlsson@intel.com,
mudongliangabcd@gmail.com, netdev@vger.kernel.org,
songliubraving@fb.com, syzkaller-bugs@googlegroups.com,
torvalds@linux-foundation.org, yhs@fb.com
Subject: Re: [syzbot] WARNING: kmalloc bug in xdp_umem_create (2)
Date: Thu, 10 Feb 2022 09:11:26 +0100 [thread overview]
Message-ID: <20220210081125.GA4616@1wt.eu> (raw)
In-Reply-To: <0000000000001f60ef05d7a3c6ad@google.com>
On Wed, Feb 09, 2022 at 10:08:07PM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 7661809d493b426e979f39ab512e3adf41fbcc69
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed Jul 14 16:45:49 2021 +0000
>
> mm: don't allow oversized kvmalloc() calls
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13bc74c2700000
> start commit: f4bc5bbb5fef Merge tag 'nfsd-5.17-2' of git://git.kernel.o..
> git tree: upstream
> final oops: https://syzkaller.appspot.com/x/report.txt?x=107c74c2700000
> console output: https://syzkaller.appspot.com/x/log.txt?x=17bc74c2700000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5707221760c00a20
> dashboard link: https://syzkaller.appspot.com/bug?extid=11421fbbff99b989670e
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12e514a4700000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15fcdf8a700000
>
> Reported-by: syzbot+11421fbbff99b989670e@syzkaller.appspotmail.com
> Fixes: 7661809d493b ("mm: don't allow oversized kvmalloc() calls")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Interesting, so in fact syzkaller has shown that the aforementioned
patch does its job well and has spotted a call path by which a single
userland setsockopt() can request more than 2 GB allocation in the
kernel. Most likely that's in fact what needs to be addressed.
FWIW the call trace at the URL above is:
Call Trace:
kvmalloc include/linux/mm.h:806 [inline]
kvmalloc_array include/linux/mm.h:824 [inline]
kvcalloc include/linux/mm.h:829 [inline]
xdp_umem_pin_pages net/xdp/xdp_umem.c:102 [inline]
xdp_umem_reg net/xdp/xdp_umem.c:219 [inline]
xdp_umem_create+0x6a5/0xf00 net/xdp/xdp_umem.c:252
xsk_setsockopt+0x604/0x790 net/xdp/xsk.c:1068
__sys_setsockopt+0x1fd/0x4e0 net/socket.c:2176
__do_sys_setsockopt net/socket.c:2187 [inline]
__se_sys_setsockopt net/socket.c:2184 [inline]
__x64_sys_setsockopt+0xb5/0x150 net/socket.c:2184
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
and the meaningful part of the repro is:
syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
intptr_t res = 0;
res = syscall(__NR_socket, 0x2cul, 3ul, 0);
if (res != -1)
r[0] = res;
*(uint64_t*)0x20000080 = 0;
*(uint64_t*)0x20000088 = 0xfff02000000;
*(uint32_t*)0x20000090 = 0x800;
*(uint32_t*)0x20000094 = 0;
*(uint32_t*)0x20000098 = 0;
syscall(__NR_setsockopt, r[0], 0x11b, 4, 0x20000080ul, 0x20ul);
Willy
next prev parent reply other threads:[~2022-02-10 8:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000000000000a3571605d27817b5@google.com>
2022-02-10 6:08 ` syzbot
2022-02-10 8:11 ` Willy Tarreau [this message]
[not found] ` <359ee592-747f-8610-4180-5e1d2aba1b77@iogearbox.net>
2022-02-10 16:18 ` Björn Töpel
2022-02-10 17:45 ` Dan Carpenter
2022-02-10 17:56 ` Dan Carpenter
2022-02-10 18:04 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220210081125.GA4616@1wt.eu \
--to=w@1wt.eu \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bjorn.topel@intel.com \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=fgheet255t@gmail.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=magnus.karlsson@intel.com \
--cc=mudongliangabcd@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=syzbot+11421fbbff99b989670e@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=torvalds@linux-foundation.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox