Re: WARNING in __alloc_pages_nodemask

[Andrey Konovalov]

On Mon, Sep 16, 2019 at 10:58 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 16, 2019 at 01:00:11PM -0700, David Rientjes wrote:
> > On Mon, 16 Sep 2019, syzbot wrote:
> > > HEAD commit:    f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
> > > git tree:       https://github.com/google/kasan.git usb-fuzzer
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14b15371600000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=e38fe539fedfc127987e
> > > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1093bed1600000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1603cfc6600000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+e38fe539fedfc127987e@xxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > WARNING: CPU: 0 PID: 1720 at mm/page_alloc.c:4696
> > > __alloc_pages_nodemask+0x36f/0x780 mm/page_alloc.c:4696
> > > Kernel panic - not syncing: panic_on_warn set ...
>
> > > alloc_pages_current+0xff/0x200 mm/mempolicy.c:2153
> > > alloc_pages include/linux/gfp.h:509 [inline]
> > > kmalloc_order+0x1a/0x60 mm/slab_common.c:1257
> > > kmalloc_order_trace+0x18/0x110 mm/slab_common.c:1269
> > > __usbhid_submit_report drivers/hid/usbhid/hid-core.c:588 [inline]
> > > usbhid_submit_report+0x5b5/0xde0 drivers/hid/usbhid/hid-core.c:638
> > > usbhid_request+0x3c/0x70 drivers/hid/usbhid/hid-core.c:1252
> > > hid_hw_request include/linux/hid.h:1053 [inline]
> > > hiddev_ioctl+0x526/0x1550 drivers/hid/usbhid/hiddev.c:735
> > Adding Jiri and Benjamin.  The hid report length is simply too large for
> > the page allocator to allocate: this is triggering because the resulting
> > allocation order is > MAX_ORDER-1.  Any way to make this allocate less
> > physically contiguous memory?
>
> The HID code should, presumably, reject reports which are larger than
> PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER.  Particularly since it's using
> GFP_ATOMIC.

This is an int underflow when doing report buffer size calculation, see here:

https://groups.google.com/d/msg/syzkaller-bugs/X0zVbh8aFEM/NsPcshjxBgAJ

#syz dup: KMSAN: kernel-usb-infoleak in hid_submit_ctrl

https://syzkaller.appspot.com/bug?extid=401d71a99cfca9fceb77