On Mon, Jul 29, 2024 at 02:31:12PM -0700, Andrew Morton wrote: > On Mon, 29 Jul 2024 08:34:33 -0700 syzbot <syzbot+ff2407cef5068e202465@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 3a7e02c040b1 minmax: avoid overly complicated constant exp.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=132e32bd980000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=381b8eb3d35e3ad9 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ff2407cef5068e202465 > > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/198814da854c/disk-3a7e02c0.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/868e99275bc0/vmlinux-3a7e02c0.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/ce63033f3708/bzImage-3a7e02c0.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+ff2407cef5068e202465@xxxxxxxxxxxxxxxxxxxxxxxxx > > Thanks. Possibly kcov_ioctl(KCOV_INIT_TRACE) was passed a crazily huge > size. Perhaps some more realistic checking should be applied there? > > Also, vmalloc() shouldn't be doing this even if asked to allocate a > crazily huge size. > <snip> diff --git a/mm/vmalloc.c b/mm/vmalloc.c index bc21d821d506..450c6b10a357 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3783,7 +3783,7 @@ void *__vmalloc_node_range_noprof(unsigned long size, unsigned long align, if (WARN_ON_ONCE(!size)) return NULL; - if ((size >> PAGE_SHIFT) > totalram_pages()) { + if ((size >> PAGE_SHIFT) > totalram_pages() || size > INT32_MAX) { warn_alloc(gfp_mask, NULL, "vmalloc error: size %lu, exceeds total pages", real_size); <snip> We can limit it to ~2GB or add a special threshold which will control the maximum allocation size. Any thoughts? -- Uladzislau Rezki
