* Re: BUG: bad usercopy in old_dev_ioctl
[not found] <001a1141c43a5f5178056084703f@google.com>
@ 2017-12-17 16:45 ` Kees Cook
2017-12-19 8:49 ` Dmitry Vyukov
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2017-12-17 16:45 UTC (permalink / raw)
To: syzbot
Cc: David Windsor, James Morse, keun-o.park, Laura Abbott, LKML,
Linux-MM, Mark Rutland, Ingo Molnar, syzkaller-bugs
On Sat, Dec 16, 2017 at 11:47 PM, syzbot
<bot+5e56fb40e0f2bc3f20402f782f0b3913cb959acc@syzkaller.appspotmail.com>
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> device gre0 entered promiscuous mode
> usercopy: kernel memory exposure attempt detected from 00000000a6830059
> (kmalloc-1024) (1024 bytes)
> ------------[ cut here ]------------
> kernel BUG at mm/usercopy.c:84!
> invalid opcode: 0000 [#1] SMP
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 28799 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:report_usercopy mm/usercopy.c:76 [inline]
> RIP: 0010:__check_object_size+0x1e2/0x250 mm/usercopy.c:276
> RSP: 0018:ffffc9000116fc50 EFLAGS: 00010286
> RAX: 0000000000000063 RBX: ffffffff82e6518f RCX: ffffffff8123dede
> RDX: 0000000000004c58 RSI: ffffc900050ed000 RDI: ffff88021fd136f8
> RBP: ffffc9000116fc88 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880216bb6050
> R13: 0000000000000400 R14: 0000000000000001 R15: ffffffff82eda864
> FS: 00007f61a06bc700(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020a5afd8 CR3: 000000020f8a9000 CR4: 00000000001406e0
> Call Trace:
> check_object_size include/linux/thread_info.h:112 [inline]
> check_copy_size include/linux/thread_info.h:143 [inline]
> copy_to_user include/linux/uaccess.h:154 [inline]
> old_dev_ioctl.isra.1+0x21d/0x9a0 net/bridge/br_ioctl.c:178
Uhh, this doesn't make sense, much like the other report...
indices = kcalloc(num, sizeof(int), GFP_KERNEL);
if (indices == NULL)
return -ENOMEM;
get_port_ifindices(br, indices, num);
if (copy_to_user((void __user *)args[1], indices,
num*sizeof(int)))
offset is 0. size overlaps. usercopy checks in -next must be broken. I
will double-check.
-Kees
> br_dev_ioctl+0x3f/0xa0 net/bridge/br_ioctl.c:392
> dev_ifsioc+0x175/0x520 net/core/dev_ioctl.c:354
> dev_ioctl+0x548/0x7a0 net/core/dev_ioctl.c:589
> sock_ioctl+0x150/0x320 net/socket.c:998
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:00007f61a06bbc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007f61a06bc700 RCX: 0000000000452a39
> RDX: 0000000020a59fd8 RSI: 00000000000089f0 RDI: 0000000000000014
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
> R13: 0000000000a6f7ff R14: 00007f61a06bc9c0 R15: 0000000000000000
> Code: 7b e5 82 48 0f 44 da e8 8d 82 eb ff 48 8b 45 d0 4d 89 e9 4c 89 e1 4c
> 89 fa 48 89 de 48 c7 c7 a8 51 e6 82 49 89 c0 e8 76 b7 e3 ff <0f> 0b 48 c7 c0
> 43 51 e6 82 eb a1 48 c7 c0 53 51 e6 82 eb 98 48
> RIP: report_usercopy mm/usercopy.c:76 [inline] RSP: ffffc9000116fc50
> RIP: __check_object_size+0x1e2/0x250 mm/usercopy.c:276 RSP: ffffc9000116fc50
> ---[ end trace 5fadb883cda020dc ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: bad usercopy in old_dev_ioctl
2017-12-17 16:45 ` BUG: bad usercopy in old_dev_ioctl Kees Cook
@ 2017-12-19 8:49 ` Dmitry Vyukov
2017-12-19 15:57 ` Kees Cook
0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Vyukov @ 2017-12-19 8:49 UTC (permalink / raw)
To: Kees Cook
Cc: syzbot, David Windsor, James Morse, keun-o.park, Laura Abbott,
LKML, Linux-MM, Mark Rutland, Ingo Molnar, syzkaller-bugs
On Sun, Dec 17, 2017 at 5:45 PM, Kees Cook <keescook@chromium.org> wrote:
> On Sat, Dec 16, 2017 at 11:47 PM, syzbot
> <bot+5e56fb40e0f2bc3f20402f782f0b3913cb959acc@syzkaller.appspotmail.com>
> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>>
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> device gre0 entered promiscuous mode
>> usercopy: kernel memory exposure attempt detected from 00000000a6830059
>> (kmalloc-1024) (1024 bytes)
>> ------------[ cut here ]------------
>> kernel BUG at mm/usercopy.c:84!
>> invalid opcode: 0000 [#1] SMP
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 28799 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
>> #67
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:report_usercopy mm/usercopy.c:76 [inline]
>> RIP: 0010:__check_object_size+0x1e2/0x250 mm/usercopy.c:276
>> RSP: 0018:ffffc9000116fc50 EFLAGS: 00010286
>> RAX: 0000000000000063 RBX: ffffffff82e6518f RCX: ffffffff8123dede
>> RDX: 0000000000004c58 RSI: ffffc900050ed000 RDI: ffff88021fd136f8
>> RBP: ffffc9000116fc88 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880216bb6050
>> R13: 0000000000000400 R14: 0000000000000001 R15: ffffffff82eda864
>> FS: 00007f61a06bc700(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000020a5afd8 CR3: 000000020f8a9000 CR4: 00000000001406e0
>> Call Trace:
>> check_object_size include/linux/thread_info.h:112 [inline]
>> check_copy_size include/linux/thread_info.h:143 [inline]
>> copy_to_user include/linux/uaccess.h:154 [inline]
>> old_dev_ioctl.isra.1+0x21d/0x9a0 net/bridge/br_ioctl.c:178
>
> Uhh, this doesn't make sense, much like the other report...
>
> indices = kcalloc(num, sizeof(int), GFP_KERNEL);
> if (indices == NULL)
> return -ENOMEM;
>
> get_port_ifindices(br, indices, num);
> if (copy_to_user((void __user *)args[1], indices,
> num*sizeof(int)))
>
> offset is 0. size overlaps. usercopy checks in -next must be broken. I
> will double-check.
Start of heap object ending at 0x59 looks bogus, right?
>> br_dev_ioctl+0x3f/0xa0 net/bridge/br_ioctl.c:392
>> dev_ifsioc+0x175/0x520 net/core/dev_ioctl.c:354
>> dev_ioctl+0x548/0x7a0 net/core/dev_ioctl.c:589
>> sock_ioctl+0x150/0x320 net/socket.c:998
>> vfs_ioctl fs/ioctl.c:46 [inline]
>> do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>> SYSC_ioctl fs/ioctl.c:701 [inline]
>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>> entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x452a39
>> RSP: 002b:00007f61a06bbc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
>> RAX: ffffffffffffffda RBX: 00007f61a06bc700 RCX: 0000000000452a39
>> RDX: 0000000020a59fd8 RSI: 00000000000089f0 RDI: 0000000000000014
>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
>> R13: 0000000000a6f7ff R14: 00007f61a06bc9c0 R15: 0000000000000000
>> Code: 7b e5 82 48 0f 44 da e8 8d 82 eb ff 48 8b 45 d0 4d 89 e9 4c 89 e1 4c
>> 89 fa 48 89 de 48 c7 c7 a8 51 e6 82 49 89 c0 e8 76 b7 e3 ff <0f> 0b 48 c7 c0
>> 43 51 e6 82 eb a1 48 c7 c0 53 51 e6 82 eb 98 48
>> RIP: report_usercopy mm/usercopy.c:76 [inline] RSP: ffffc9000116fc50
>> RIP: __check_object_size+0x1e2/0x250 mm/usercopy.c:276 RSP: ffffc9000116fc50
>> ---[ end trace 5fadb883cda020dc ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkaller@googlegroups.com.
>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>>
>> syzbot will keep track of this bug report.
>> Once a fix for this bug is merged into any tree, reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>
>
>
> --
> Kees Cook
> Pixel Security
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAGXu5jLAvE9GaF%3DVdzR%3DwrUpquDSJkUXCidZMU-qb02%2BFDZW6g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: bad usercopy in old_dev_ioctl
2017-12-19 8:49 ` Dmitry Vyukov
@ 2017-12-19 15:57 ` Kees Cook
2017-12-19 16:35 ` Dmitry Vyukov
0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2017-12-19 15:57 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, David Windsor, James Morse, keun-o.park, Laura Abbott,
LKML, Linux-MM, Mark Rutland, Ingo Molnar, syzkaller-bugs
On Tue, Dec 19, 2017 at 12:49 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Sun, Dec 17, 2017 at 5:45 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Sat, Dec 16, 2017 at 11:47 PM, syzbot
>> <bot+5e56fb40e0f2bc3f20402f782f0b3913cb959acc@syzkaller.appspotmail.com>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>>
>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>
>>>
>>> device gre0 entered promiscuous mode
>>> usercopy: kernel memory exposure attempt detected from 00000000a6830059
>>> (kmalloc-1024) (1024 bytes)
>>> ------------[ cut here ]------------
>>> kernel BUG at mm/usercopy.c:84!
>>> invalid opcode: 0000 [#1] SMP
>>> Dumping ftrace buffer:
>>> (ftrace buffer empty)
>>> Modules linked in:
>>> CPU: 1 PID: 28799 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
>>> #67
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> RIP: 0010:report_usercopy mm/usercopy.c:76 [inline]
>>> RIP: 0010:__check_object_size+0x1e2/0x250 mm/usercopy.c:276
>>> RSP: 0018:ffffc9000116fc50 EFLAGS: 00010286
>>> RAX: 0000000000000063 RBX: ffffffff82e6518f RCX: ffffffff8123dede
>>> RDX: 0000000000004c58 RSI: ffffc900050ed000 RDI: ffff88021fd136f8
>>> RBP: ffffc9000116fc88 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880216bb6050
>>> R13: 0000000000000400 R14: 0000000000000001 R15: ffffffff82eda864
>>> FS: 00007f61a06bc700(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000000020a5afd8 CR3: 000000020f8a9000 CR4: 00000000001406e0
>>> Call Trace:
>>> check_object_size include/linux/thread_info.h:112 [inline]
>>> check_copy_size include/linux/thread_info.h:143 [inline]
>>> copy_to_user include/linux/uaccess.h:154 [inline]
>>> old_dev_ioctl.isra.1+0x21d/0x9a0 net/bridge/br_ioctl.c:178
>>
>> Uhh, this doesn't make sense, much like the other report...
>>
>> indices = kcalloc(num, sizeof(int), GFP_KERNEL);
>> if (indices == NULL)
>> return -ENOMEM;
>>
>> get_port_ifindices(br, indices, num);
>> if (copy_to_user((void __user *)args[1], indices,
>> num*sizeof(int)))
>>
>> offset is 0. size overlaps. usercopy checks in -next must be broken. I
>> will double-check.
>
>
> Start of heap object ending at 0x59 looks bogus, right?
No, that's a hashed address. %p doesn't report real addresses any more.
-Kees
>
>
>>> br_dev_ioctl+0x3f/0xa0 net/bridge/br_ioctl.c:392
>>> dev_ifsioc+0x175/0x520 net/core/dev_ioctl.c:354
>>> dev_ioctl+0x548/0x7a0 net/core/dev_ioctl.c:589
>>> sock_ioctl+0x150/0x320 net/socket.c:998
>>> vfs_ioctl fs/ioctl.c:46 [inline]
>>> do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>>> SYSC_ioctl fs/ioctl.c:701 [inline]
>>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>> entry_SYSCALL_64_fastpath+0x1f/0x96
>>> RIP: 0033:0x452a39
>>> RSP: 002b:00007f61a06bbc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
>>> RAX: ffffffffffffffda RBX: 00007f61a06bc700 RCX: 0000000000452a39
>>> RDX: 0000000020a59fd8 RSI: 00000000000089f0 RDI: 0000000000000014
>>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
>>> R13: 0000000000a6f7ff R14: 00007f61a06bc9c0 R15: 0000000000000000
>>> Code: 7b e5 82 48 0f 44 da e8 8d 82 eb ff 48 8b 45 d0 4d 89 e9 4c 89 e1 4c
>>> 89 fa 48 89 de 48 c7 c7 a8 51 e6 82 49 89 c0 e8 76 b7 e3 ff <0f> 0b 48 c7 c0
>>> 43 51 e6 82 eb a1 48 c7 c0 53 51 e6 82 eb 98 48
>>> RIP: report_usercopy mm/usercopy.c:76 [inline] RSP: ffffc9000116fc50
>>> RIP: __check_object_size+0x1e2/0x250 mm/usercopy.c:276 RSP: ffffc9000116fc50
>>> ---[ end trace 5fadb883cda020dc ]---
>>> Kernel panic - not syncing: Fatal exception
>>> Dumping ftrace buffer:
>>> (ftrace buffer empty)
>>> Kernel Offset: disabled
>>> Rebooting in 86400 seconds..
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkaller@googlegroups.com.
>>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>>>
>>> syzbot will keep track of this bug report.
>>> Once a fix for this bug is merged into any tree, reply to this email with:
>>> #syz fix: exact-commit-title
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>
>>
>>
>> --
>> Kees Cook
>> Pixel Security
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAGXu5jLAvE9GaF%3DVdzR%3DwrUpquDSJkUXCidZMU-qb02%2BFDZW6g%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: bad usercopy in old_dev_ioctl
2017-12-19 15:57 ` Kees Cook
@ 2017-12-19 16:35 ` Dmitry Vyukov
2017-12-31 8:10 ` Dmitry Vyukov
0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Vyukov @ 2017-12-19 16:35 UTC (permalink / raw)
To: Kees Cook
Cc: syzbot, David Windsor, James Morse, keun-o.park, Laura Abbott,
LKML, Linux-MM, Mark Rutland, Ingo Molnar, syzkaller-bugs
On Tue, Dec 19, 2017 at 4:57 PM, Kees Cook <keescook@chromium.org> wrote:
>>> <bot+5e56fb40e0f2bc3f20402f782f0b3913cb959acc@syzkaller.appspotmail.com>
>>> wrote:
>>>> Hello,
>>>>
>>>> syzkaller hit the following crash on
>>>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>> .config is attached
>>>> Raw console output is attached.
>>>>
>>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>>
>>>>
>>>> device gre0 entered promiscuous mode
>>>> usercopy: kernel memory exposure attempt detected from 00000000a6830059
>>>> (kmalloc-1024) (1024 bytes)
>>>> ------------[ cut here ]------------
>>>> kernel BUG at mm/usercopy.c:84!
>>>> invalid opcode: 0000 [#1] SMP
>>>> Dumping ftrace buffer:
>>>> (ftrace buffer empty)
>>>> Modules linked in:
>>>> CPU: 1 PID: 28799 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
>>>> #67
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>> Google 01/01/2011
>>>> RIP: 0010:report_usercopy mm/usercopy.c:76 [inline]
>>>> RIP: 0010:__check_object_size+0x1e2/0x250 mm/usercopy.c:276
>>>> RSP: 0018:ffffc9000116fc50 EFLAGS: 00010286
>>>> RAX: 0000000000000063 RBX: ffffffff82e6518f RCX: ffffffff8123dede
>>>> RDX: 0000000000004c58 RSI: ffffc900050ed000 RDI: ffff88021fd136f8
>>>> RBP: ffffc9000116fc88 R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880216bb6050
>>>> R13: 0000000000000400 R14: 0000000000000001 R15: ffffffff82eda864
>>>> FS: 00007f61a06bc700(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 0000000020a5afd8 CR3: 000000020f8a9000 CR4: 00000000001406e0
>>>> Call Trace:
>>>> check_object_size include/linux/thread_info.h:112 [inline]
>>>> check_copy_size include/linux/thread_info.h:143 [inline]
>>>> copy_to_user include/linux/uaccess.h:154 [inline]
>>>> old_dev_ioctl.isra.1+0x21d/0x9a0 net/bridge/br_ioctl.c:178
>>>
>>> Uhh, this doesn't make sense, much like the other report...
>>>
>>> indices = kcalloc(num, sizeof(int), GFP_KERNEL);
>>> if (indices == NULL)
>>> return -ENOMEM;
>>>
>>> get_port_ifindices(br, indices, num);
>>> if (copy_to_user((void __user *)args[1], indices,
>>> num*sizeof(int)))
>>>
>>> offset is 0. size overlaps. usercopy checks in -next must be broken. I
>>> will double-check.
>>
>>
>> Start of heap object ending at 0x59 looks bogus, right?
>
> No, that's a hashed address. %p doesn't report real addresses any more.
Ah, for some reason I thought that 64-bit hashing just strips upper
part (because what would be a reason to strip it from a hash? and
showing lower bytes is useful and does not reveal too much).
>>>> br_dev_ioctl+0x3f/0xa0 net/bridge/br_ioctl.c:392
>>>> dev_ifsioc+0x175/0x520 net/core/dev_ioctl.c:354
>>>> dev_ioctl+0x548/0x7a0 net/core/dev_ioctl.c:589
>>>> sock_ioctl+0x150/0x320 net/socket.c:998
>>>> vfs_ioctl fs/ioctl.c:46 [inline]
>>>> do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>>>> SYSC_ioctl fs/ioctl.c:701 [inline]
>>>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>>> entry_SYSCALL_64_fastpath+0x1f/0x96
>>>> RIP: 0033:0x452a39
>>>> RSP: 002b:00007f61a06bbc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
>>>> RAX: ffffffffffffffda RBX: 00007f61a06bc700 RCX: 0000000000452a39
>>>> RDX: 0000000020a59fd8 RSI: 00000000000089f0 RDI: 0000000000000014
>>>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>>>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
>>>> R13: 0000000000a6f7ff R14: 00007f61a06bc9c0 R15: 0000000000000000
>>>> Code: 7b e5 82 48 0f 44 da e8 8d 82 eb ff 48 8b 45 d0 4d 89 e9 4c 89 e1 4c
>>>> 89 fa 48 89 de 48 c7 c7 a8 51 e6 82 49 89 c0 e8 76 b7 e3 ff <0f> 0b 48 c7 c0
>>>> 43 51 e6 82 eb a1 48 c7 c0 53 51 e6 82 eb 98 48
>>>> RIP: report_usercopy mm/usercopy.c:76 [inline] RSP: ffffc9000116fc50
>>>> RIP: __check_object_size+0x1e2/0x250 mm/usercopy.c:276 RSP: ffffc9000116fc50
>>>> ---[ end trace 5fadb883cda020dc ]---
>>>> Kernel panic - not syncing: Fatal exception
>>>> Dumping ftrace buffer:
>>>> (ftrace buffer empty)
>>>> Kernel Offset: disabled
>>>> Rebooting in 86400 seconds..
>>>>
>>>>
>>>> ---
>>>> This bug is generated by a dumb bot. It may contain errors.
>>>> See https://goo.gl/tpsmEJ for details.
>>>> Direct all questions to syzkaller@googlegroups.com.
>>>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>>>>
>>>> syzbot will keep track of this bug report.
>>>> Once a fix for this bug is merged into any tree, reply to this email with:
>>>> #syz fix: exact-commit-title
>>>> To mark this as a duplicate of another syzbot report, please reply with:
>>>> #syz dup: exact-subject-of-another-report
>>>> If it's a one-off invalid bug report, please reply with:
>>>> #syz invalid
>>>> Note: if the crash happens again, it will cause creation of a new bug
>>>> report.
>>>> Note: all commands must start from beginning of the line in the email body.
>>>
>>>
>>>
>>> --
>>> Kees Cook
>>> Pixel Security
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAGXu5jLAvE9GaF%3DVdzR%3DwrUpquDSJkUXCidZMU-qb02%2BFDZW6g%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Kees Cook
> Pixel Security
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: BUG: bad usercopy in old_dev_ioctl
2017-12-19 16:35 ` Dmitry Vyukov
@ 2017-12-31 8:10 ` Dmitry Vyukov
0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2017-12-31 8:10 UTC (permalink / raw)
To: Kees Cook
Cc: syzbot, David Windsor, James Morse, keun-o.park, Laura Abbott,
LKML, Linux-MM, Mark Rutland, Ingo Molnar, syzkaller-bugs
On Tue, Dec 19, 2017 at 5:35 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Dec 19, 2017 at 4:57 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> <bot+5e56fb40e0f2bc3f20402f782f0b3913cb959acc@syzkaller.appspotmail.com>
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> syzkaller hit the following crash on
>>>>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>> .config is attached
>>>>> Raw console output is attached.
>>>>>
>>>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>>>
>>>>>
>>>>> device gre0 entered promiscuous mode
>>>>> usercopy: kernel memory exposure attempt detected from 00000000a6830059
>>>>> (kmalloc-1024) (1024 bytes)
>>>>> ------------[ cut here ]------------
>>>>> kernel BUG at mm/usercopy.c:84!
>>>>> invalid opcode: 0000 [#1] SMP
>>>>> Dumping ftrace buffer:
>>>>> (ftrace buffer empty)
>>>>> Modules linked in:
>>>>> CPU: 1 PID: 28799 Comm: syz-executor4 Not tainted 4.15.0-rc3-next-20171214+
>>>>> #67
>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>>> Google 01/01/2011
>>>>> RIP: 0010:report_usercopy mm/usercopy.c:76 [inline]
>>>>> RIP: 0010:__check_object_size+0x1e2/0x250 mm/usercopy.c:276
>>>>> RSP: 0018:ffffc9000116fc50 EFLAGS: 00010286
>>>>> RAX: 0000000000000063 RBX: ffffffff82e6518f RCX: ffffffff8123dede
>>>>> RDX: 0000000000004c58 RSI: ffffc900050ed000 RDI: ffff88021fd136f8
>>>>> RBP: ffffc9000116fc88 R08: 0000000000000000 R09: 0000000000000000
>>>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff880216bb6050
>>>>> R13: 0000000000000400 R14: 0000000000000001 R15: ffffffff82eda864
>>>>> FS: 00007f61a06bc700(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> CR2: 0000000020a5afd8 CR3: 000000020f8a9000 CR4: 00000000001406e0
>>>>> Call Trace:
>>>>> check_object_size include/linux/thread_info.h:112 [inline]
>>>>> check_copy_size include/linux/thread_info.h:143 [inline]
>>>>> copy_to_user include/linux/uaccess.h:154 [inline]
>>>>> old_dev_ioctl.isra.1+0x21d/0x9a0 net/bridge/br_ioctl.c:178
>>>>
>>>> Uhh, this doesn't make sense, much like the other report...
>>>>
>>>> indices = kcalloc(num, sizeof(int), GFP_KERNEL);
>>>> if (indices == NULL)
>>>> return -ENOMEM;
>>>>
>>>> get_port_ifindices(br, indices, num);
>>>> if (copy_to_user((void __user *)args[1], indices,
>>>> num*sizeof(int)))
>>>>
>>>> offset is 0. size overlaps. usercopy checks in -next must be broken. I
>>>> will double-check.
>>>
>>>
>>> Start of heap object ending at 0x59 looks bogus, right?
>>
>> No, that's a hashed address. %p doesn't report real addresses any more.
>
> Ah, for some reason I thought that 64-bit hashing just strips upper
> part (because what would be a reason to strip it from a hash? and
> showing lower bytes is useful and does not reveal too much).
>
>>>>> br_dev_ioctl+0x3f/0xa0 net/bridge/br_ioctl.c:392
>>>>> dev_ifsioc+0x175/0x520 net/core/dev_ioctl.c:354
>>>>> dev_ioctl+0x548/0x7a0 net/core/dev_ioctl.c:589
>>>>> sock_ioctl+0x150/0x320 net/socket.c:998
>>>>> vfs_ioctl fs/ioctl.c:46 [inline]
>>>>> do_vfs_ioctl+0xaf/0x840 fs/ioctl.c:686
>>>>> SYSC_ioctl fs/ioctl.c:701 [inline]
>>>>> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>>>> entry_SYSCALL_64_fastpath+0x1f/0x96
>>>>> RIP: 0033:0x452a39
>>>>> RSP: 002b:00007f61a06bbc58 EFLAGS: 00000212 ORIG_RAX: 0000000000000010
>>>>> RAX: ffffffffffffffda RBX: 00007f61a06bc700 RCX: 0000000000452a39
>>>>> RDX: 0000000020a59fd8 RSI: 00000000000089f0 RDI: 0000000000000014
>>>>> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>>>>> R10: 0000000000000000 R11: 0000000000000212 R12: 0000000000000000
>>>>> R13: 0000000000a6f7ff R14: 00007f61a06bc9c0 R15: 0000000000000000
>>>>> Code: 7b e5 82 48 0f 44 da e8 8d 82 eb ff 48 8b 45 d0 4d 89 e9 4c 89 e1 4c
>>>>> 89 fa 48 89 de 48 c7 c7 a8 51 e6 82 49 89 c0 e8 76 b7 e3 ff <0f> 0b 48 c7 c0
>>>>> 43 51 e6 82 eb a1 48 c7 c0 53 51 e6 82 eb 98 48
>>>>> RIP: report_usercopy mm/usercopy.c:76 [inline] RSP: ffffc9000116fc50
>>>>> RIP: __check_object_size+0x1e2/0x250 mm/usercopy.c:276 RSP: ffffc9000116fc50
>>>>> ---[ end trace 5fadb883cda020dc ]---
>>>>> Kernel panic - not syncing: Fatal exception
>>>>> Dumping ftrace buffer:
>>>>> (ftrace buffer empty)
>>>>> Kernel Offset: disabled
>>>>> Rebooting in 86400 seconds..
>>>>>
>>>>>
>>>>> ---
>>>>> This bug is generated by a dumb bot. It may contain errors.
>>>>> See https://goo.gl/tpsmEJ for details.
>>>>> Direct all questions to syzkaller@googlegroups.com.
>>>>> Please credit me with: Reported-by: syzbot <syzkaller@googlegroups.com>
>>>>>
>>>>> syzbot will keep track of this bug report.
>>>>> Once a fix for this bug is merged into any tree, reply to this email with:
>>>>> #syz fix: exact-commit-title
>>>>> To mark this as a duplicate of another syzbot report, please reply with:
>>>>> #syz dup: exact-subject-of-another-report
>>>>> If it's a one-off invalid bug report, please reply with:
>>>>> #syz invalid
>>>>> Note: if the crash happens again, it will cause creation of a new bug
>>>>> report.
>>>>> Note: all commands must start from beginning of the line in the email body.
Bad things on kmalloc-1024 are most likely caused by an invalid free
in pcrypt, it freed a pointer into a middle of a 1024 byte heap object
which was undetected by KASAN (now there is a patch for this in mm
tree) and later caused all kinds of bad things:
https://groups.google.com/forum/#!topic/syzkaller-bugs/NKn_ivoPOpk
https://patchwork.kernel.org/patch/10126761/
#syz dup: KASAN: use-after-free Read in __list_del_entry_valid (2)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-12-31 8:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <001a1141c43a5f5178056084703f@google.com>
2017-12-17 16:45 ` BUG: bad usercopy in old_dev_ioctl Kees Cook
2017-12-19 8:49 ` Dmitry Vyukov
2017-12-19 15:57 ` Kees Cook
2017-12-19 16:35 ` Dmitry Vyukov
2017-12-31 8:10 ` Dmitry Vyukov
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).