KASAN: use-after-free Read in __bpf_prog_put

[syzbot]

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+d85bfb...@syzkaller.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
==================================================================


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.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.

[Dmitry Vyukov]

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 syzk...@googlegroups.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-bug...@googlegroups.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.

[Daniel Borkmann]

Hi Dmitry,

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

[Eric Biggers]

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