general protection fault in tcp_v6_connect

general protection fault in tcp_v6_connect

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    f4aa8012 cxgb4: Make t4_get_tp_e2c_map static
git tree:       net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1662cb12a00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d137eb988ffd93c3
dashboard link: https://syzkaller.appspot.com/bug?extid=5ee26b4e30c45930bd3c
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+5ee26b4e30c45930bd3c@syzkaller.appspotmail.com

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 17324 Comm: syz-executor.5 Not tainted 5.2.0-rc1+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
RIP: 0010:rt6_get_cookie include/net/ip6_fib.h:264 [inline]
RIP: 0010:ip6_dst_store include/net/ip6_route.h:213 [inline]
RIP: 0010:tcp_v6_connect+0xfd0/0x20a0 net/ipv6/tcp_ipv6.c:298
Code: 89 e6 e8 83 a2 48 fb 45 84 e4 0f 84 90 09 00 00 e8 35 a1 48 fb 49 8d  
7e 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 57 0e 00 00 4d 8b 66 70 e8 4d 88 35 fb 31 ff 89
RSP: 0018:ffff888066547800 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff888064e839f0 RCX: ffffc90010e49000
RDX: 000000000000002b RSI: ffffffff8628033b RDI: 000000000000015f
RBP: ffff888066547980 R08: ffff8880a9412080 R09: ffffed1015d26be0
R10: ffffed1015d26bdf R11: ffff8880ae935efb R12: 0000000000000001
R13: ffff888064e82f40 R14: 00000000000000ef R15: ffff888066547de8
FS:  00007f43abb71700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffc77267668 CR3: 00000000a5071000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  __inet_stream_connect+0x834/0xe90 net/ipv4/af_inet.c:659
  tcp_sendmsg_fastopen net/ipv4/tcp.c:1143 [inline]
  tcp_sendmsg_locked+0x2318/0x3920 net/ipv4/tcp.c:1185
  tcp_sendmsg+0x30/0x50 net/ipv4/tcp.c:1419
  inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:802
  sock_sendmsg_nosec net/socket.c:652 [inline]
  sock_sendmsg+0xd7/0x130 net/socket.c:671
  __sys_sendto+0x262/0x380 net/socket.c:1964
  __do_sys_sendto net/socket.c:1976 [inline]
  __se_sys_sendto net/socket.c:1972 [inline]
  __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1972
  do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459279
Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f43abb70c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 0000000000459279
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 000000000075c100 R08: 0000000020000380 R09: 000000000000001c
R10: 0000000020000000 R11: 0000000000000246 R12: 00007f43abb716d4
R13: 00000000004c6d9d R14: 00000000004dbc40 R15: 00000000ffffffff
Modules linked in:
---[ end trace c8448517bbb9ef43 ]---
RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
RIP: 0010:rt6_get_cookie include/net/ip6_fib.h:264 [inline]
RIP: 0010:ip6_dst_store include/net/ip6_route.h:213 [inline]
RIP: 0010:tcp_v6_connect+0xfd0/0x20a0 net/ipv6/tcp_ipv6.c:298
Code: 89 e6 e8 83 a2 48 fb 45 84 e4 0f 84 90 09 00 00 e8 35 a1 48 fb 49 8d  
7e 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 57 0e 00 00 4d 8b 66 70 e8 4d 88 35 fb 31 ff 89
RSP: 0018:ffff888066547800 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff888064e839f0 RCX: ffffc90010e49000
RDX: 000000000000002b RSI: ffffffff8628033b RDI: 000000000000015f
RBP: ffff888066547980 R08: ffff8880a9412080 R09: ffffed1015d26be0
R10: ffffed1015d26bdf R11: ffff8880ae935efb R12: 0000000000000001
R13: ffff888064e82f40 R14: 00000000000000ef R15: ffff888066547de8
FS:  00007f43abb71700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f86924a7000 CR3: 00000000a5071000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: general protection fault in tcp_v6_connect

[David Ahern]

On 6/1/19 12:05 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    f4aa8012 cxgb4: Make t4_get_tp_e2c_map static
> git tree:       net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1662cb12a00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d137eb988ffd93c3
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=5ee26b4e30c45930bd3c
> 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+5ee26b4e30c45930bd3c@syzkaller.appspotmail.com
> 
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 17324 Comm: syz-executor.5 Not tainted 5.2.0-rc1+ #2
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
> RIP: 0010:rt6_get_cookie include/net/ip6_fib.h:264 [inline]
> RIP: 0010:ip6_dst_store include/net/ip6_route.h:213 [inline]
> RIP: 0010:tcp_v6_connect+0xfd0/0x20a0 net/ipv6/tcp_ipv6.c:298
> Code: 89 e6 e8 83 a2 48 fb 45 84 e4 0f 84 90 09 00 00 e8 35 a1 48 fb 49
> 8d 7e 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02
> 00 0f 85 57 0e 00 00 4d 8b 66 70 e8 4d 88 35 fb 31 ff 89
> RSP: 0018:ffff888066547800 EFLAGS: 00010207
> RAX: dffffc0000000000 RBX: ffff888064e839f0 RCX: ffffc90010e49000
> RDX: 000000000000002b RSI: ffffffff8628033b RDI: 000000000000015f
> RBP: ffff888066547980 R08: ffff8880a9412080 R09: ffffed1015d26be0

This one is not so obvious.

The error has to be a bad dst from ip6_dst_lookup_flow called by
tcp_v6_connect which then is attempted to be stored in the socket via
ip6_dst_store. ip6_dst_store calls rt6_get_cookie with dst as the
argument. RDI (first arg for x86) shows 0x15f which is not a valid and
would cause a fault.

None of the ip6_dst_* functions in net/ipv6/ip6_output.c have changed
recently (5.2-next definitely but I believe this true for many releases
prior). Further, all of the FIB lookup functions (called by
ip6_dst_lookup_flow) always return a non-NULL dst.

If my hunch about the other splat is correct (pcpu corruption) that
could explain this one: FIB lookup is fine and finds an entry, the entry
has a pcpu cache entry so it is returned. If the pcpu entry was stomped
on then it would be invalid and the above would result.

Re: general protection fault in tcp_v6_connect

[Dmitry Vyukov]

On Mon, Jun 3, 2019 at 5:29 AM David Ahern <dsahern@gmail.com> wrote:
>
> On 6/1/19 12:05 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:    f4aa8012 cxgb4: Make t4_get_tp_e2c_map static
> > git tree:       net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1662cb12a00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=d137eb988ffd93c3
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=5ee26b4e30c45930bd3c
> > 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+5ee26b4e30c45930bd3c@syzkaller.appspotmail.com
> >
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: 0000 [#1] PREEMPT SMP KASAN
> > CPU: 1 PID: 17324 Comm: syz-executor.5 Not tainted 5.2.0-rc1+ #2
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
> > RIP: 0010:rt6_get_cookie include/net/ip6_fib.h:264 [inline]
> > RIP: 0010:ip6_dst_store include/net/ip6_route.h:213 [inline]
> > RIP: 0010:tcp_v6_connect+0xfd0/0x20a0 net/ipv6/tcp_ipv6.c:298
> > Code: 89 e6 e8 83 a2 48 fb 45 84 e4 0f 84 90 09 00 00 e8 35 a1 48 fb 49
> > 8d 7e 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02
> > 00 0f 85 57 0e 00 00 4d 8b 66 70 e8 4d 88 35 fb 31 ff 89
> > RSP: 0018:ffff888066547800 EFLAGS: 00010207
> > RAX: dffffc0000000000 RBX: ffff888064e839f0 RCX: ffffc90010e49000
> > RDX: 000000000000002b RSI: ffffffff8628033b RDI: 000000000000015f
> > RBP: ffff888066547980 R08: ffff8880a9412080 R09: ffffed1015d26be0
>
> This one is not so obvious.
>
> The error has to be a bad dst from ip6_dst_lookup_flow called by
> tcp_v6_connect which then is attempted to be stored in the socket via
> ip6_dst_store. ip6_dst_store calls rt6_get_cookie with dst as the
> argument. RDI (first arg for x86) shows 0x15f which is not a valid and
> would cause a fault.
>
> None of the ip6_dst_* functions in net/ipv6/ip6_output.c have changed
> recently (5.2-next definitely but I believe this true for many releases
> prior). Further, all of the FIB lookup functions (called by
> ip6_dst_lookup_flow) always return a non-NULL dst.
>
> If my hunch about the other splat is correct (pcpu corruption) that
> could explain this one: FIB lookup is fine and finds an entry, the entry
> has a pcpu cache entry so it is returned. If the pcpu entry was stomped
> on then it would be invalid and the above would result.


This happened only once so far, so may be a previous silent memory corruption.

This also may be related to "KASAN: user-memory-access Read in
ip6_hold_safe (3)":
https://syzkaller.appspot.com/bug?extid=a5b6e01ec8116d046842
because that one seems to be a race in involved code.
So this one may be a rare incarnation of the other crash.