linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* BUG: bad usercopy in hidraw_ioctl
@ 2019-08-07 19:28 syzbot
  2019-08-07 19:58 ` Matthew Wilcox
  2019-08-21 17:00 ` Andrey Konovalov
  0 siblings, 2 replies; 6+ messages in thread
From: syzbot @ 2019-08-07 19:28 UTC (permalink / raw)
  To: allison, andreyknvl, cai, gregkh, keescook, linux-kernel,
	linux-mm, linux-usb, syzkaller-bugs, tglx

Hello,

syzbot found the following crash on:

HEAD commit:    e96407b4 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=151b2926600000
kernel config:  https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
dashboard link: https://syzkaller.appspot.com/bug?extid=3de312463756f656b47d
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3de312463756f656b47d@syzkaller.appspotmail.com

usercopy: Kernel memory exposure attempt detected from wrapped address  
(offset 0, size 0)!
------------[ cut here ]------------
kernel BUG at mm/usercopy.c:98!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 1 PID: 2968 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:98
Code: e8 c1 f7 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 e0  
f3 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 15 98 c1 ff <0f> 0b e8 95 f7  
d6 ff e8 80 9f fd ff 8b 54 24 04 49 89 d8 4c 89 e1
RSP: 0018:ffff8881b0f37be8 EFLAGS: 00010282
RAX: 000000000000005a RBX: ffffffff85cdf100 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed10361e6f6f
RBP: ffffffff85cdf2c0 R08: 000000000000005a R09: ffffed103b665d58
R10: ffffed103b665d57 R11: ffff8881db32eabf R12: ffffffff85cdf460
R13: ffffffff85cdf100 R14: 0000000000000000 R15: ffffffff85cdf100
FS:  00007f539a2a9700(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000021237d0 CR3: 00000001d6ac6000 CR4: 00000000001406e0
Call Trace:
  check_bogus_address mm/usercopy.c:151 [inline]
  __check_object_size mm/usercopy.c:260 [inline]
  __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
  check_object_size include/linux/thread_info.h:119 [inline]
  check_copy_size include/linux/thread_info.h:150 [inline]
  copy_to_user include/linux/uaccess.h:151 [inline]
  hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
  vfs_ioctl fs/ioctl.c:46 [inline]
  file_ioctl fs/ioctl.c:509 [inline]
  do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
  ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
  __do_sys_ioctl fs/ioctl.c:720 [inline]
  __se_sys_ioctl fs/ioctl.c:718 [inline]
  __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
  do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f539a2a8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
RDX: 0000000020000800 RSI: 0000000090044802 RDI: 0000000000000004
RBP: 000000000075c268 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f539a2a96d4
R13: 00000000004c21f3 R14: 00000000004d55b8 R15: 00000000ffffffff
Modules linked in:
---[ end trace 24b9968555bf4653 ]---
RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:98
Code: e8 c1 f7 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 e0  
f3 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 15 98 c1 ff <0f> 0b e8 95 f7  
d6 ff e8 80 9f fd ff 8b 54 24 04 49 89 d8 4c 89 e1
RSP: 0018:ffff8881b0f37be8 EFLAGS: 00010282
RAX: 000000000000005a RBX: ffffffff85cdf100 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed10361e6f6f
RBP: ffffffff85cdf2c0 R08: 000000000000005a R09: ffffed103b665d58
R10: ffffed103b665d57 R11: ffff8881db32eabf R12: ffffffff85cdf460
R13: ffffffff85cdf100 R14: 0000000000000000 R15: ffffffff85cdf100
FS:  00007f539a2a9700(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000021237d0 CR3: 00000001d6ac6000 CR4: 00000000001406e0


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG: bad usercopy in hidraw_ioctl
  2019-08-07 19:28 BUG: bad usercopy in hidraw_ioctl syzbot
@ 2019-08-07 19:58 ` Matthew Wilcox
  2019-08-08  1:49   ` Al Viro
  2019-08-08 20:27   ` Kees Cook
  2019-08-21 17:00 ` Andrey Konovalov
  1 sibling, 2 replies; 6+ messages in thread
From: Matthew Wilcox @ 2019-08-07 19:58 UTC (permalink / raw)
  To: syzbot
  Cc: allison, andreyknvl, cai, gregkh, keescook, linux-kernel,
	linux-mm, linux-usb, syzkaller-bugs, tglx, Jiri Kosina

On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> usercopy: Kernel memory exposure attempt detected from wrapped address
> (offset 0, size 0)!
> ------------[ cut here ]------------
> kernel BUG at mm/usercopy.c:98!

This report is confusing because the arguments to usercopy_abort() are wrong.

        /* Reject if object wraps past end of memory. */
        if (ptr + n < ptr)
                usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);

ptr + n is not 'size', it's what wrapped.  I don't know what 'offset'
should be set to, but 'size' should be 'n'.  Presumably we don't want to
report 'ptr' because it'll leak a kernel address ... reporting 'n' will
leak a range for a kernel address, but I think that's OK?  Admittedly an
attacker can pass in various values for 'n', but it'll be quite noisy
and leave a trace in the kernel logs for forensics to find afterwards.

> Call Trace:
>  check_bogus_address mm/usercopy.c:151 [inline]
>  __check_object_size mm/usercopy.c:260 [inline]
>  __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
>  check_object_size include/linux/thread_info.h:119 [inline]
>  check_copy_size include/linux/thread_info.h:150 [inline]
>  copy_to_user include/linux/uaccess.h:151 [inline]
>  hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392

The root problem would appear to be:

                                else if (copy_to_user(user_arg + offsetof(
                                        struct hidraw_report_descriptor,
                                        value[0]),
                                        dev->hid->rdesc,
                                        min(dev->hid->rsize, len)))

That 'min' should surely be a 'max'?

Jiri, this looks like it was your code back in 2007.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG: bad usercopy in hidraw_ioctl
  2019-08-07 19:58 ` Matthew Wilcox
@ 2019-08-08  1:49   ` Al Viro
  2019-08-08 20:41     ` Kees Cook
  2019-08-08 20:27   ` Kees Cook
  1 sibling, 1 reply; 6+ messages in thread
From: Al Viro @ 2019-08-08  1:49 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: syzbot, allison, andreyknvl, cai, gregkh, keescook, linux-kernel,
	linux-mm, linux-usb, syzkaller-bugs, tglx, Jiri Kosina

On Wed, Aug 07, 2019 at 12:58:21PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> > usercopy: Kernel memory exposure attempt detected from wrapped address
> > (offset 0, size 0)!
> > ------------[ cut here ]------------
> > kernel BUG at mm/usercopy.c:98!
> 
> This report is confusing because the arguments to usercopy_abort() are wrong.
> 
>         /* Reject if object wraps past end of memory. */
>         if (ptr + n < ptr)
>                 usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);
> 
> ptr + n is not 'size', it's what wrapped.  I don't know what 'offset'
> should be set to, but 'size' should be 'n'.  Presumably we don't want to
> report 'ptr' because it'll leak a kernel address ... reporting 'n' will
> leak a range for a kernel address, but I think that's OK?  Admittedly an
> attacker can pass in various values for 'n', but it'll be quite noisy
> and leave a trace in the kernel logs for forensics to find afterwards.
> 
> > Call Trace:
> >  check_bogus_address mm/usercopy.c:151 [inline]
> >  __check_object_size mm/usercopy.c:260 [inline]
> >  __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
> >  check_object_size include/linux/thread_info.h:119 [inline]
> >  check_copy_size include/linux/thread_info.h:150 [inline]
> >  copy_to_user include/linux/uaccess.h:151 [inline]
> >  hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
> 
> The root problem would appear to be:
> 
>                                 else if (copy_to_user(user_arg + offsetof(
>                                         struct hidraw_report_descriptor,
>                                         value[0]),
>                                         dev->hid->rdesc,
>                                         min(dev->hid->rsize, len)))
> 
> That 'min' should surely be a 'max'?

Surely not.  ->rsize is the amount of data available to copy out; len
is the size of buffer supplied by userland to copy into.

BTW, why is it playing those games with offsetof, anyway?  What's wrong
with
	struct hidraw_report_descriptor __user *p = user_arg;
	...
	get_user(&p->size)
	...
	copy_to_user(p->value, ...)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG: bad usercopy in hidraw_ioctl
  2019-08-07 19:58 ` Matthew Wilcox
  2019-08-08  1:49   ` Al Viro
@ 2019-08-08 20:27   ` Kees Cook
  1 sibling, 0 replies; 6+ messages in thread
From: Kees Cook @ 2019-08-08 20:27 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: syzbot, allison, andreyknvl, cai, gregkh, linux-kernel, linux-mm,
	linux-usb, syzkaller-bugs, tglx, Jiri Kosina

On Wed, Aug 07, 2019 at 12:58:21PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> > usercopy: Kernel memory exposure attempt detected from wrapped address
> > (offset 0, size 0)!
> > ------------[ cut here ]------------
> > kernel BUG at mm/usercopy.c:98!
> 
> This report is confusing because the arguments to usercopy_abort() are wrong.
> 
>         /* Reject if object wraps past end of memory. */
>         if (ptr + n < ptr)
>                 usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);

This test actually contains an off-by-one which was recently fixed:
https://lore.kernel.org/linux-mm/1564509253-23287-1-git-send-email-isaacm@codeaurora.org/

So, this is actually a false positive if "ptr + n" yields a 0
(e.g. 0xffffffff + 1 == 0).

> ptr + n is not 'size', it's what wrapped.  I don't know what 'offset'
> should be set to, but 'size' should be 'n'.  Presumably we don't want to
> report 'ptr' because it'll leak a kernel address ... reporting 'n' will

Right, I left offset 0 (this is normally the offset into a reported area
like a specific kmalloc region, but isn't meaningful here IMO). And I
left the size as "how far we wrapped". (Which is pretty telling: we
wrapped 0 bytes ... *cough*.)

> leak a range for a kernel address, but I think that's OK?  Admittedly an
> attacker can pass in various values for 'n', but it'll be quite noisy
> and leave a trace in the kernel logs for forensics to find afterwards.
> 
> > Call Trace:
> >  check_bogus_address mm/usercopy.c:151 [inline]
> >  __check_object_size mm/usercopy.c:260 [inline]
> >  __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
> >  check_object_size include/linux/thread_info.h:119 [inline]
> >  check_copy_size include/linux/thread_info.h:150 [inline]
> >  copy_to_user include/linux/uaccess.h:151 [inline]
> >  hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
> 
> The root problem would appear to be:
> 
>                                 else if (copy_to_user(user_arg + offsetof(
>                                         struct hidraw_report_descriptor,
>                                         value[0]),
>                                         dev->hid->rdesc,
>                                         min(dev->hid->rsize, len)))
> 
> That 'min' should surely be a 'max'?
> 
> Jiri, this looks like it was your code back in 2007.

I think this code is correct and the usercopy reporting fix already in
-mm solves the problem.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG: bad usercopy in hidraw_ioctl
  2019-08-08  1:49   ` Al Viro
@ 2019-08-08 20:41     ` Kees Cook
  0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2019-08-08 20:41 UTC (permalink / raw)
  To: Al Viro
  Cc: Matthew Wilcox, syzbot, allison, andreyknvl, cai, gregkh,
	linux-kernel, linux-mm, linux-usb, syzkaller-bugs, tglx,
	Jiri Kosina

On Thu, Aug 08, 2019 at 02:49:25AM +0100, Al Viro wrote:
> On Wed, Aug 07, 2019 at 12:58:21PM -0700, Matthew Wilcox wrote:
> > On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> > > usercopy: Kernel memory exposure attempt detected from wrapped address
> > > (offset 0, size 0)!
> > > ------------[ cut here ]------------
> > > kernel BUG at mm/usercopy.c:98!
> > 
> > This report is confusing because the arguments to usercopy_abort() are wrong.
> > 
> >         /* Reject if object wraps past end of memory. */
> >         if (ptr + n < ptr)
> >                 usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);

(Just to reiterate for this branch of the thread: this is an off-by-one
false positive already fixed in -mm for -next. However, see below...)

> > 
> > ptr + n is not 'size', it's what wrapped.  I don't know what 'offset'
> > should be set to, but 'size' should be 'n'.  Presumably we don't want to
> > report 'ptr' because it'll leak a kernel address ... reporting 'n' will
> > leak a range for a kernel address, but I think that's OK?  Admittedly an
> > attacker can pass in various values for 'n', but it'll be quite noisy
> > and leave a trace in the kernel logs for forensics to find afterwards.
> > 
> > > Call Trace:
> > >  check_bogus_address mm/usercopy.c:151 [inline]
> > >  __check_object_size mm/usercopy.c:260 [inline]
> > >  __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
> > >  check_object_size include/linux/thread_info.h:119 [inline]
> > >  check_copy_size include/linux/thread_info.h:150 [inline]
> > >  copy_to_user include/linux/uaccess.h:151 [inline]
> > >  hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
> > 
> > The root problem would appear to be:
> > 
> >                                 else if (copy_to_user(user_arg + offsetof(
> >                                         struct hidraw_report_descriptor,
> >                                         value[0]),
> >                                         dev->hid->rdesc,
> >                                         min(dev->hid->rsize, len)))
> > 
> > That 'min' should surely be a 'max'?
> 
> Surely not.  ->rsize is the amount of data available to copy out; len
> is the size of buffer supplied by userland to copy into.

include/uapi/linux/hid.h:#define HID_MAX_DESCRIPTOR_SIZE 4096

drivers/hid/hidraw.c:
                        if (get_user(len, (int __user *)arg))
                                ret = -EFAULT;
                        else if (len > HID_MAX_DESCRIPTOR_SIZE - 1)
                                ret = -EINVAL;
                        else if (copy_to_user(user_arg + offsetof(
                                struct hidraw_report_descriptor,
                                value[0]),
                                dev->hid->rdesc,
                                min(dev->hid->rsize, len)))
                                ret = -EFAULT;

The copy size must be less than 4096, which means dev->hid->rdesc is
allocated at the highest page of memory. That whole space collides with
the ERR_PTR region which has two bad potential side-effects:

1) something that checks for ERR_PTRs combined with a high allocation
will think it failed and leak the allocation.

2) something that doesn't check ERR_PTRs might try to stomp on an actual
allocation in that area.

How/why is there memory allocated there, I thought it was intentionally
left unused specifically for ERR_PTR:

Documentation/x86/x86_64/mm.rst:

     Start addr    | Offset |     End addr     | Size  | VM area description
  ==========================================================================
  ...
  ffffffffffe00000 | -2  MB | ffffffffffffffff |  2 MB | ...unused hole


or is this still a real bug with an invalid dev->hid->rdesc which was
about to fault but usercopy got in the way first?

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG: bad usercopy in hidraw_ioctl
  2019-08-07 19:28 BUG: bad usercopy in hidraw_ioctl syzbot
  2019-08-07 19:58 ` Matthew Wilcox
@ 2019-08-21 17:00 ` Andrey Konovalov
  1 sibling, 0 replies; 6+ messages in thread
From: Andrey Konovalov @ 2019-08-21 17:00 UTC (permalink / raw)
  To: syzbot
  Cc: allison, Qian Cai, Greg Kroah-Hartman, Kees Cook, LKML,
	Linux Memory Management List, USB list, syzkaller-bugs,
	Thomas Gleixner

On Wed, Aug 7, 2019 at 9:28 PM syzbot
<syzbot+3de312463756f656b47d@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    e96407b4 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=151b2926600000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=cfa2c18fb6a8068e
> dashboard link: https://syzkaller.appspot.com/bug?extid=3de312463756f656b47d
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3de312463756f656b47d@syzkaller.appspotmail.com
>
> usercopy: Kernel memory exposure attempt detected from wrapped address
> (offset 0, size 0)!
> ------------[ cut here ]------------
> kernel BUG at mm/usercopy.c:98!
> invalid opcode: 0000 [#1] SMP KASAN
> CPU: 1 PID: 2968 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #25
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:98
> Code: e8 c1 f7 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 e0
> f3 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 15 98 c1 ff <0f> 0b e8 95 f7
> d6 ff e8 80 9f fd ff 8b 54 24 04 49 89 d8 4c 89 e1
> RSP: 0018:ffff8881b0f37be8 EFLAGS: 00010282
> RAX: 000000000000005a RBX: ffffffff85cdf100 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed10361e6f6f
> RBP: ffffffff85cdf2c0 R08: 000000000000005a R09: ffffed103b665d58
> R10: ffffed103b665d57 R11: ffff8881db32eabf R12: ffffffff85cdf460
> R13: ffffffff85cdf100 R14: 0000000000000000 R15: ffffffff85cdf100
> FS:  00007f539a2a9700(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000021237d0 CR3: 00000001d6ac6000 CR4: 00000000001406e0
> Call Trace:
>   check_bogus_address mm/usercopy.c:151 [inline]
>   __check_object_size mm/usercopy.c:260 [inline]
>   __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
>   check_object_size include/linux/thread_info.h:119 [inline]
>   check_copy_size include/linux/thread_info.h:150 [inline]
>   copy_to_user include/linux/uaccess.h:151 [inline]
>   hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
>   vfs_ioctl fs/ioctl.c:46 [inline]
>   file_ioctl fs/ioctl.c:509 [inline]
>   do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
>   ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
>   __do_sys_ioctl fs/ioctl.c:720 [inline]
>   __se_sys_ioctl fs/ioctl.c:718 [inline]
>   __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
>   do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
>   entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x459829
> Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f539a2a8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
> RDX: 0000000020000800 RSI: 0000000090044802 RDI: 0000000000000004
> RBP: 000000000075c268 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f539a2a96d4
> R13: 00000000004c21f3 R14: 00000000004d55b8 R15: 00000000ffffffff
> Modules linked in:
> ---[ end trace 24b9968555bf4653 ]---
> RIP: 0010:usercopy_abort+0xb9/0xbb mm/usercopy.c:98
> Code: e8 c1 f7 d6 ff 49 89 d9 4d 89 e8 4c 89 e1 41 56 48 89 ee 48 c7 c7 e0
> f3 cd 85 ff 74 24 08 41 57 48 8b 54 24 20 e8 15 98 c1 ff <0f> 0b e8 95 f7
> d6 ff e8 80 9f fd ff 8b 54 24 04 49 89 d8 4c 89 e1
> RSP: 0018:ffff8881b0f37be8 EFLAGS: 00010282
> RAX: 000000000000005a RBX: ffffffff85cdf100 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed10361e6f6f
> RBP: ffffffff85cdf2c0 R08: 000000000000005a R09: ffffed103b665d58
> R10: ffffed103b665d57 R11: ffff8881db32eabf R12: ffffffff85cdf460
> R13: ffffffff85cdf100 R14: 0000000000000000 R15: ffffffff85cdf100
> FS:  00007f539a2a9700(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000021237d0 CR3: 00000001d6ac6000 CR4: 00000000001406e0
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Looks like the same bug:

#syz dup: KASAN: slab-out-of-bounds Read in hidraw_ioctl

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-08-21 17:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-07 19:28 BUG: bad usercopy in hidraw_ioctl syzbot
2019-08-07 19:58 ` Matthew Wilcox
2019-08-08  1:49   ` Al Viro
2019-08-08 20:41     ` Kees Cook
2019-08-08 20:27   ` Kees Cook
2019-08-21 17:00 ` Andrey Konovalov

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).