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