linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: syzbot <syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	syzkaller-bugs@googlegroups.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org
Subject: Re: [syzbot] WARNING in do_proc_bulk
Date: Mon, 3 May 2021 14:56:14 -0400	[thread overview]
Message-ID: <20210503185614.GA628313@rowland.harvard.edu> (raw)
In-Reply-To: <20210503105351.0966275d0d9e001ed794de2c@linux-foundation.org>

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

  reply	other threads:[~2021-05-03 18:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-02 20:00 [syzbot] WARNING in do_proc_bulk syzbot
2021-05-03 10:25 ` syzbot
2021-05-03 17:53   ` Andrew Morton
2021-05-03 18:56     ` Alan Stern [this message]
2021-05-03 19:24       ` Andrew Morton
2021-05-04  0:47         ` Alan Stern
2021-05-04  1:07           ` syzbot

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=20210503185614.GA628313@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.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;
as well as URLs for NNTP newsgroup(s).