Re: KASAN: user-memory-access Read in ip6_hold_safe (3)

[David Ahern <dsahern@gmail.com>]

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+a5b6e01ec8116d046842@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).