lkml.org 
[lkml]   [2021]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [syzbot] WARNING in do_proc_bulk
On Mon, May 03, 2021 at 10:53:51AM -0700, Andrew Morton wrote:
> (cc usb peeps)
>
> On Mon, 03 May 2021 03:25:21 -0700 syzbot <syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com> wrote:
>
> > syzbot has found a reproducer for the following issue on:
>
> Thanks.
>
> > HEAD commit: d2b6f8a1 Merge tag 'xfs-5.13-merge-3' of git://git.kernel...
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1746d3e1d00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=65c207250bba4efe
> > dashboard link: https://syzkaller.appspot.com/bug?extid=882a85c0c8ec4a3e2281
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=107f7893d00000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ae7ca5d00000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com
> >
> > usb usb9: usbfs: process 8586 (syz-executor862) did not claim interface 0 before use
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 8586 at mm/page_alloc.c:4985 __alloc_pages_nodemask+0x5fd/0x730 mm/page_alloc.c:5020
> > Modules linked in:
> > CPU: 0 PID: 8586 Comm: syz-executor862 Not tainted 5.12.0-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > RIP: 0010:__alloc_pages_nodemask+0x5fd/0x730 mm/page_alloc.c:4985
> > Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 9b d7 ff ff 49 89 c5 e9 e5 fc ff ff <0f> 0b e9 b0 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8
> > RSP: 0018:ffffc90001f57a30 EFLAGS: 00010246
> > RAX: 0000000000000000 RBX: 1ffff920003eaf4a RCX: 0000000000000000
> > RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000040cc0
> > RBP: 0000000000040cc0 R08: 0000000000000000 R09: 0000000000000000
> > R10: ffffffff81b51b41 R11: 0000000000000000 R12: 000000000000000b
> > R13: 000000000000000b R14: 0000000000000000 R15: 0000000000554e47
> > FS: 0000000002293300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fd2526f7008 CR3: 000000001d80b000 CR4: 00000000001506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2277
> > alloc_pages include/linux/gfp.h:561 [inline]
> > kmalloc_order+0x34/0xf0 mm/slab_common.c:906
> > kmalloc_order_trace+0x14/0x130 mm/slab_common.c:922
> > kmalloc include/linux/slab.h:561 [inline]
> > do_proc_bulk+0x2d4/0x750 drivers/usb/core/devio.c:1221
> > proc_bulk drivers/usb/core/devio.c:1268 [inline]
> > usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
> > usbdev_ioctl+0x586/0x36c0 drivers/usb/core/devio.c:2708
> > vfs_ioctl fs/ioctl.c:51 [inline]
> > __do_sys_ioctl fs/ioctl.c:1069 [inline]
> > __se_sys_ioctl fs/ioctl.c:1055 [inline]
> > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055
> > do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
> > entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> do_proc_bulk() is asking kmalloc for more than MAX_ORDER bytes, in
>
> tbuf = kmalloc(len1, GFP_KERNEL);

This doesn't seem to be a bug. do_proc_bulk is simply trying to
allocate a kernel buffer for data passed to/from userspace. If a user
wants too much space all at once, that's their problem.

As far as I know, the kmalloc API doesn't require the caller to filter
out requests for more the MAX_ORDER bytes. Only to be prepared to
handle failures -- which do_proc_bulk is all set for.

Am I wrong about this? Should we add __GFP_NOWARN to the gfp flags?

Alan Stern

\
 
 \ /
  Last update: 2021-05-03 20:57    [W:0.086 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site