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