Re: KASAN: use-after-free Read in __bpf_prog_put

[Eric Biggers]

On Thu, Jan 11, 2018 at 11:48:28AM +0100, Daniel Borkmann wrote:
> Hi Dmitry,
> 
> On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> > On Thu, Jan 11, 2018 at 11:17 AM, syzbot
> > <syzbot+d85bfb332db8f0794212@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> >> 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 one in bpf tree fixes it:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1
> 
> Despite this one not having a reproducer, I'm pretty certain it's very
> much related to all the ones coming in yesterday (which the above fixes).
> 
> >> This bug is generated by a dumb bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for details.
> >> Direct all questions to syzkaller@xxxxxxxxxxxxxxxxx
> >>
> >> 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

This particular crash has not re-occurred following the initial report, so I'll
assume the above analysis is correct and it was indeed fixed by:

#syz fix: bpf, array: fix overflow in max_entries and undefined behavior in index_mask

- Eric