lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Jan 2018 11:22:12 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     syzbot <syzbot+d85bfb332db8f0794212@...kaller.appspotmail.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>, syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: use-after-free Read in __bpf_prog_put

On Thu, Jan 11, 2018 at 11:17 AM, syzbot
<syzbot+d85bfb332db8f0794212@...kaller.appspotmail.com> wrote:
> Hello,
>
> syzkaller hit the following crash on
> 4147d50978df60f34d444c647dde9e5b34a4315e
> git://git.cmpxchg.org/linux-mmots.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.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d85bfb332db8f0794212@...kaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> netlink: 3 bytes leftover after parsing attributes in process
> `syz-executor5'.
> ==================================================================
> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
> kernel/bpf/syscall.c:944
> netlink: 'syz-executor5': attribute type 5 has an invalid length.
> Read of size 8 at addr ffff8801d3619658 by task syz-executor0/12398
>
> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
>  bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
>  prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
>  fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
>  map_delete_elem kernel/bpf/syscall.c:737 [inline]
>  SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
>  SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x452ac9
> RSP: 002b:00007fb70df60c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
> RDX: 0000000000000010 RSI: 0000000020f02ff0 RDI: 0000000000000003
> RBP: 00000000000003aa R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f3890
> R13: 00000000ffffffff R14: 00007fb70df616d4 R15: 0000000000000000
>
> Allocated by task 11996:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>  kmem_cache_zalloc include/linux/slab.h:694 [inline]
>  get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
>  path_openat+0xed/0x3530 fs/namei.c:3514
>  do_filp_open+0x25b/0x3b0 fs/namei.c:3572
>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>  SYSC_open fs/open.c:1077 [inline]
>  SyS_open+0x2d/0x40 fs/open.c:1072
>  entry_SYSCALL_64_fastpath+0x29/0xa0
>
> Freed by task 11994:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>  file_free_rcu+0x5c/0x70 fs/file_table.c:49
>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> The buggy address belongs to the object at ffff8801d36195c0
>  which belongs to the cache filp of size 456
> The buggy address is located 152 bytes inside of
>  456-byte region [ffff8801d36195c0, ffff8801d3619788)
> The buggy address belongs to the page:
> page:ffffea00074d8640 count:1 mapcount:0 mapping:ffff8801d36190c0 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801d36190c0 0000000000000000 0000000100000006
> raw: ffffea00074c49a0 ffffea000747a160 ffff8801dae30180 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  ffff8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>
>> ffff8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
>                                                     ^
>  ffff8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================


Is it the same as "general protection fault in __bpf_prog_put"?
https://groups.google.com/forum/#!topic/syzkaller-bugs/jUsNMmVgms0

The first stack looks similar, but alloc/free stacks looks unrelated.
What's the root cause of this? Is prog->aux an uninitialized pointer?
I wonder if initializing memory in kmalloc would help to prevent this
bug from duplicating? E.g. if we init memory to 0, it would always
cause GPFs, or if we init to an invalid pointer, always cause a bad
paging fault. Is it's the case, then I think we should do it to reduce
number of failure modes and syzbot reports.


> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@...glegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please 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.
>
> --
> 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@...glegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a1140bf605479be05627d75c7%40google.com.
> For more options, visit https://groups.google.com/d/optout.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ