On 6/1/19 12:05 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: dfb569f2 net: ll_temac: Fix compile error
just an FYI: this is before any of my IPv6 changes in 5.2-next that are relevant. At this commit the only IPv6 changes of mine are: 19a3b7eea424 ipv6: export function to send route updates cdaa16a4f70c ipv6: Add hook to bump sernum for a route to stubs 68a9b13d9219 ipv6: Add delete route hook to stubs which are function exports - unused at commit dfb569f2. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=10afcb8aa00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=fc045131472947d7 > dashboard link: > https://syzkaller.appspot.com/bug?extid=a5b6e01ec8116d046842 > 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+a5b6e01ec8116d046...@syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: user-memory-access in atomic_read > include/asm-generic/atomic-instrumented.h:26 [inline] > BUG: KASAN: user-memory-access in atomic_fetch_add_unless > include/linux/atomic-fallback.h:1086 [inline] > BUG: KASAN: user-memory-access in atomic_add_unless > include/linux/atomic-fallback.h:1111 [inline] > BUG: KASAN: user-memory-access in atomic_inc_not_zero > include/linux/atomic-fallback.h:1127 [inline] > BUG: KASAN: user-memory-access in dst_hold_safe include/net/dst.h:297 > [inline] > BUG: KASAN: user-memory-access in ip6_hold_safe+0xad/0x380 > net/ipv6/route.c:1050 > Read of size 4 at addr 0000000000001ec4 by task syz-executor.0/10106 0xc1ec4 is not a valid address for an allocated rt6_info. > > CPU: 0 PID: 10106 Comm: syz-executor.0 Not tainted 5.2.0-rc1+ #5 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x172/0x1f0 lib/dump_stack.c:113 > __kasan_report.cold+0x5/0x40 mm/kasan/report.c:321 > kasan_report+0x12/0x20 mm/kasan/common.c:614 > check_memory_region_inline mm/kasan/generic.c:185 [inline] > check_memory_region+0x123/0x190 mm/kasan/generic.c:191 > kasan_check_read+0x11/0x20 mm/kasan/common.c:94 > atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] > atomic_fetch_add_unless include/linux/atomic-fallback.h:1086 [inline] > atomic_add_unless include/linux/atomic-fallback.h:1111 [inline] > atomic_inc_not_zero include/linux/atomic-fallback.h:1127 [inline] > dst_hold_safe include/net/dst.h:297 [inline] > ip6_hold_safe+0xad/0x380 net/ipv6/route.c:1050 > rt6_get_pcpu_route net/ipv6/route.c:1277 [inline] My hunch is that this is memory corruption in the pcpu memory space. In a fib6_info, rt6i_pcpu is non-NULL for ALL fib6_info except fib6_null_entry for which pcpu routes are never generated. rt6i_pcpu is allocated via pcpu_alloc which means this memory space is amongst other pcpu users and easily stepped on by other pcpu users. The entries stored in rt6_pcpu are kmem_cache entries for the ipv6 dst cache and either a valid allocated memory address or NULL. Past issues with pcpu routes was the 'from' (the fib6_info used to generate the rt6_info) being NULL (several), the fib entry getting released more than it should (0e2338749192) or not getting freed at all (61fb0d016807).
