linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* KMSAN: kernel-infoleak in sctp_getsockopt (3)
@ 2019-03-28 16:25 syzbot
  2019-03-29 14:50 ` Neil Horman
  0 siblings, 1 reply; 7+ messages in thread
From: syzbot @ 2019-03-28 16:25 UTC (permalink / raw)
  To: davem, glider, linux-kernel, linux-sctp, marcelo.leitner, netdev,
	nhorman, syzkaller-bugs, vyasevich

Hello,

syzbot found the following crash on:

HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
git tree:       kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
compiler:       clang version 8.0.0 (trunk 350509)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com

IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
8021q: adding VLAN 0 to HW filter on device batadv0
8021q: adding VLAN 0 to HW filter on device batadv0
==================================================================
BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
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+0x173/0x1d0 lib/dump_stack.c:113
  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
  copy_to_user include/linux/uaccess.h:174 [inline]
  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
  __sys_getsockopt+0x489/0x550 net/socket.c:1938
  __do_sys_getsockopt net/socket.c:1949 [inline]
  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
  entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x458209
Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff

Uninit was stored to memory at:
  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
  __sys_getsockopt+0x489/0x550 net/socket.c:1938
  __do_sys_getsockopt net/socket.c:1949 [inline]
  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
  entry_SYSCALL_64_after_hwframe+0x63/0xe7

Uninit was stored to memory at:
  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
  sctp_transport_init net/sctp/transport.c:61 [inline]
  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
  sk_backlog_rcv include/net/sock.h:936 [inline]
  __release_sock+0x281/0x5f0 net/core/sock.c:2284
  release_sock+0x99/0x2a0 net/core/sock.c:2800
  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
  sock_sendmsg_nosec net/socket.c:622 [inline]
  sock_sendmsg net/socket.c:632 [inline]
  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
  __sys_sendmsg net/socket.c:2153 [inline]
  __do_sys_sendmsg net/socket.c:2162 [inline]
  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
  entry_SYSCALL_64_after_hwframe+0x63/0xe7

Local variable description: ----addr.i@sctp_process_init
Variable was created at:
  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191

Bytes 8-15 of 16 are uninitialized
Memory access of size 16 starts at ffff88809511fc28
Data copied to user address 0000000020000298
==================================================================


---
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.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-28 16:25 KMSAN: kernel-infoleak in sctp_getsockopt (3) syzbot
@ 2019-03-29 14:50 ` Neil Horman
  2019-03-29 17:35   ` Alexander Potapenko
  0 siblings, 1 reply; 7+ messages in thread
From: Neil Horman @ 2019-03-29 14:50 UTC (permalink / raw)
  To: syzbot
  Cc: davem, glider, linux-kernel, linux-sctp, marcelo.leitner, netdev,
	syzkaller-bugs, vyasevich

On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> git tree:       kmsan
> console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> compiler:       clang version 8.0.0 (trunk 350509)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> 
> IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> 8021q: adding VLAN 0 to HW filter on device batadv0
> 8021q: adding VLAN 0 to HW filter on device batadv0
> ==================================================================
> BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> 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+0x173/0x1d0 lib/dump_stack.c:113
>  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
>  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
>  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
>  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
>  copy_to_user include/linux/uaccess.h:174 [inline]
>  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
>  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
>  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
>  __sys_getsockopt+0x489/0x550 net/socket.c:1938
>  __do_sys_getsockopt net/socket.c:1949 [inline]
>  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
>  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
>  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
>  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> RIP: 0033:0x458209
> Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> 
> Uninit was stored to memory at:
>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
>  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
>  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
>  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
>  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
>  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
>  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
>  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
>  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
>  __sys_getsockopt+0x489/0x550 net/socket.c:1938
>  __do_sys_getsockopt net/socket.c:1949 [inline]
>  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
>  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
>  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
>  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> 
> Uninit was stored to memory at:
>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
>  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
>  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
>  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
>  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
>  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
>  sctp_transport_init net/sctp/transport.c:61 [inline]
>  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
>  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
>  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
>  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
>  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
>  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
>  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
>  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
>  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
>  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
>  sk_backlog_rcv include/net/sock.h:936 [inline]
>  __release_sock+0x281/0x5f0 net/core/sock.c:2284
>  release_sock+0x99/0x2a0 net/core/sock.c:2800
>  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
>  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
>  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
>  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
>  sock_sendmsg_nosec net/socket.c:622 [inline]
>  sock_sendmsg net/socket.c:632 [inline]
>  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
>  __sys_sendmsg net/socket.c:2153 [inline]
>  __do_sys_sendmsg net/socket.c:2162 [inline]
>  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
>  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
>  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
>  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> 
> Local variable description: ----addr.i@sctp_process_init
> Variable was created at:
>  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
>  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
>  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
>  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
>  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> 
> Bytes 8-15 of 16 are uninitialized
> Memory access of size 16 starts at ffff88809511fc28
> Data copied to user address 0000000020000298
> ==================================================================
> 
> 
> ---
> 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.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
> 
> 


Hmm, odd.  I see where we are doing the copy_to_user call in
getsockopt_peer_addrs, but the length we copy should always be equal to or less
than what was memcopied to the temp variable.  False positive?

Neil


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-29 14:50 ` Neil Horman
@ 2019-03-29 17:35   ` Alexander Potapenko
  2019-03-29 18:30     ` Neil Horman
  0 siblings, 1 reply; 7+ messages in thread
From: Alexander Potapenko @ 2019-03-29 17:35 UTC (permalink / raw)
  To: Neil Horman
  Cc: syzbot, David Miller, LKML, linux-sctp, Marcelo Ricardo Leitner,
	Networking, syzkaller-bugs, Vladislav Yasevich

On Fri, Mar 29, 2019 at 3:51 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> > git tree:       kmsan
> > console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> > dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> > compiler:       clang version 8.0.0 (trunk 350509)
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> >
> > IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> > IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> > 8021q: adding VLAN 0 to HW filter on device batadv0
> > 8021q: adding VLAN 0 to HW filter on device batadv0
> > ==================================================================
> > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> > 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+0x173/0x1d0 lib/dump_stack.c:113
> >  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
> >  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
> >  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
> >  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> >  copy_to_user include/linux/uaccess.h:174 [inline]
> >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
> >  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
> >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> >  __do_sys_getsockopt net/socket.c:1949 [inline]
> >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > RIP: 0033:0x458209
> > Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> > RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> > RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> > R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> > R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> >
> > Uninit was stored to memory at:
> >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
> >  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
> >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> >  __do_sys_getsockopt net/socket.c:1949 [inline]
> >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> >
> > Uninit was stored to memory at:
> >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> >  sctp_transport_init net/sctp/transport.c:61 [inline]
> >  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
> >  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
> >  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
> >  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
> >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> >  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
> >  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
> >  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
> >  sk_backlog_rcv include/net/sock.h:936 [inline]
> >  __release_sock+0x281/0x5f0 net/core/sock.c:2284
> >  release_sock+0x99/0x2a0 net/core/sock.c:2800
> >  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
> >  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
> >  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
> >  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
> >  sock_sendmsg_nosec net/socket.c:622 [inline]
> >  sock_sendmsg net/socket.c:632 [inline]
> >  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
> >  __sys_sendmsg net/socket.c:2153 [inline]
> >  __do_sys_sendmsg net/socket.c:2162 [inline]
> >  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
> >  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
> >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> >
> > Local variable description: ----addr.i@sctp_process_init
> > Variable was created at:
> >  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
> >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> >
> > Bytes 8-15 of 16 are uninitialized
> > Memory access of size 16 starts at ffff88809511fc28
> > Data copied to user address 0000000020000298
> > ==================================================================
> >
> >
> > ---
> > 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.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> >
> >
>
>
> Hmm, odd.  I see where we are doing the copy_to_user call in
> getsockopt_peer_addrs, but the length we copy should always be equal to or less
> than what was memcopied to the temp variable.  False positive?
I'll take a closer look next week.
The bug is reproducible with the following syzkaller program:

r0 = socket$inet(0x2, 0x80001, 0x84)
bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e20, @empty}, 0x10)
sendmsg(r0, &(0x7f0000000100)={&(0x7f0000006000)=@in={0x2, 0x4e20,
@loopback}, 0x80, &(0x7f0000007f80)=[{&(0x7f00000001c0)="de", 0x1}],
0x1}, 0x0)
getsockopt$inet_sctp_SCTP_GET_PEER_ADDRS(r0, 0x84, 0x6c,
&(0x7f0000000000)={<r5=>0x0, 0x38,
"41925f90e4121fadc9c1296dd22ae19d0b1b0942e46fc79e2ecec1056b23199f0ca008915d8dba1b3896c154f2244bbe859fe3423a4b437a"},
&(0x7f0000000040)=0x40)

Just need to check where the uninitializedness comes from.
> Neil
>



--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-29 17:35   ` Alexander Potapenko
@ 2019-03-29 18:30     ` Neil Horman
  2019-03-29 18:51       ` Dmitry Vyukov
  0 siblings, 1 reply; 7+ messages in thread
From: Neil Horman @ 2019-03-29 18:30 UTC (permalink / raw)
  To: Alexander Potapenko
  Cc: syzbot, David Miller, LKML, linux-sctp, Marcelo Ricardo Leitner,
	Networking, syzkaller-bugs, Vladislav Yasevich

On Fri, Mar 29, 2019 at 06:35:40PM +0100, Alexander Potapenko wrote:
> On Fri, Mar 29, 2019 at 3:51 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> > > git tree:       kmsan
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> > > compiler:       clang version 8.0.0 (trunk 350509)
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> > >
> > > IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> > > IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > ==================================================================
> > > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> > > 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+0x173/0x1d0 lib/dump_stack.c:113
> > >  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
> > >  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
> > >  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
> > >  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > >  copy_to_user include/linux/uaccess.h:174 [inline]
> > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
> > >  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
> > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > RIP: 0033:0x458209
> > > Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> > > RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> > > RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> > > R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> > > R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> > >
> > > Uninit was stored to memory at:
> > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
> > >  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
> > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > >
> > > Uninit was stored to memory at:
> > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > >  sctp_transport_init net/sctp/transport.c:61 [inline]
> > >  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
> > >  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
> > >  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
> > >  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
> > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > >  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
> > >  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
> > >  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
> > >  sk_backlog_rcv include/net/sock.h:936 [inline]
> > >  __release_sock+0x281/0x5f0 net/core/sock.c:2284
> > >  release_sock+0x99/0x2a0 net/core/sock.c:2800
> > >  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
> > >  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
> > >  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
> > >  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
> > >  sock_sendmsg_nosec net/socket.c:622 [inline]
> > >  sock_sendmsg net/socket.c:632 [inline]
> > >  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
> > >  __sys_sendmsg net/socket.c:2153 [inline]
> > >  __do_sys_sendmsg net/socket.c:2162 [inline]
> > >  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
> > >  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
> > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > >
> > > Local variable description: ----addr.i@sctp_process_init
> > > Variable was created at:
> > >  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
> > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > >
> > > Bytes 8-15 of 16 are uninitialized
> > > Memory access of size 16 starts at ffff88809511fc28
> > > Data copied to user address 0000000020000298
> > > ==================================================================
> > >
> > >
> > > ---
> > > 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.
> > > syzbot can test patches for this bug, for details see:
> > > https://goo.gl/tpsmEJ#testing-patches
> > >
> > >
> >
> >
> > Hmm, odd.  I see where we are doing the copy_to_user call in
> > getsockopt_peer_addrs, but the length we copy should always be equal to or less
> > than what was memcopied to the temp variable.  False positive?
> I'll take a closer look next week.
> The bug is reproducible with the following syzkaller program:
> 
> r0 = socket$inet(0x2, 0x80001, 0x84)
> bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e20, @empty}, 0x10)
> sendmsg(r0, &(0x7f0000000100)={&(0x7f0000006000)=@in={0x2, 0x4e20,
> @loopback}, 0x80, &(0x7f0000007f80)=[{&(0x7f00000001c0)="de", 0x1}],
> 0x1}, 0x0)
> getsockopt$inet_sctp_SCTP_GET_PEER_ADDRS(r0, 0x84, 0x6c,
> &(0x7f0000000000)={<r5=>0x0, 0x38,
> "41925f90e4121fadc9c1296dd22ae19d0b1b0942e46fc79e2ecec1056b23199f0ca008915d8dba1b3896c154f2244bbe859fe3423a4b437a"},
> &(0x7f0000000040)=0x40)
> 
> Just need to check where the uninitializedness comes from.
my only guess would be if we somehow copied an ipv4 address worth of data to the
buffer (which contains an enum for both ipv4 and ipv6 addresses), and then
copied an ipv6 address worth of data to userspace, but I don't yet see how that
can happen.

Neil

> > Neil
> >
> 
> 
> 
> --
> Alexander Potapenko
> Software Engineer
> 
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-29 18:30     ` Neil Horman
@ 2019-03-29 18:51       ` Dmitry Vyukov
  2019-03-30  7:20         ` Xin Long
  0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Vyukov @ 2019-03-29 18:51 UTC (permalink / raw)
  To: Neil Horman
  Cc: Alexander Potapenko, syzbot, David Miller, LKML, linux-sctp,
	Marcelo Ricardo Leitner, Networking, syzkaller-bugs,
	Vladislav Yasevich

On Fri, Mar 29, 2019 at 7:31 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Fri, Mar 29, 2019 at 06:35:40PM +0100, Alexander Potapenko wrote:
> > On Fri, Mar 29, 2019 at 3:51 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> > > > git tree:       kmsan
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> > > > compiler:       clang version 8.0.0 (trunk 350509)
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> > > >
> > > > IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> > > > IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > ==================================================================
> > > > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > > CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> > > > 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+0x173/0x1d0 lib/dump_stack.c:113
> > > >  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
> > > >  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
> > > >  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
> > > >  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > >  copy_to_user include/linux/uaccess.h:174 [inline]
> > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
> > > >  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
> > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > RIP: 0033:0x458209
> > > > Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > > RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > > > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> > > > RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> > > > RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> > > > R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> > > > R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> > > >
> > > > Uninit was stored to memory at:
> > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
> > > >  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
> > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > >
> > > > Uninit was stored to memory at:
> > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > >  sctp_transport_init net/sctp/transport.c:61 [inline]
> > > >  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
> > > >  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
> > > >  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
> > > >  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
> > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > >  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
> > > >  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
> > > >  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
> > > >  sk_backlog_rcv include/net/sock.h:936 [inline]
> > > >  __release_sock+0x281/0x5f0 net/core/sock.c:2284
> > > >  release_sock+0x99/0x2a0 net/core/sock.c:2800
> > > >  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
> > > >  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
> > > >  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
> > > >  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
> > > >  sock_sendmsg_nosec net/socket.c:622 [inline]
> > > >  sock_sendmsg net/socket.c:632 [inline]
> > > >  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
> > > >  __sys_sendmsg net/socket.c:2153 [inline]
> > > >  __do_sys_sendmsg net/socket.c:2162 [inline]
> > > >  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
> > > >  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
> > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > >
> > > > Local variable description: ----addr.i@sctp_process_init
> > > > Variable was created at:
> > > >  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
> > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > >
> > > > Bytes 8-15 of 16 are uninitialized
> > > > Memory access of size 16 starts at ffff88809511fc28
> > > > Data copied to user address 0000000020000298
> > > > ==================================================================
> > > >
> > > >
> > > > ---
> > > > 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.
> > > > syzbot can test patches for this bug, for details see:
> > > > https://goo.gl/tpsmEJ#testing-patches
> > > >
> > > >
> > >
> > >
> > > Hmm, odd.  I see where we are doing the copy_to_user call in
> > > getsockopt_peer_addrs, but the length we copy should always be equal to or less
> > > than what was memcopied to the temp variable.  False positive?
> > I'll take a closer look next week.
> > The bug is reproducible with the following syzkaller program:
> >
> > r0 = socket$inet(0x2, 0x80001, 0x84)
> > bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e20, @empty}, 0x10)
> > sendmsg(r0, &(0x7f0000000100)={&(0x7f0000006000)=@in={0x2, 0x4e20,
> > @loopback}, 0x80, &(0x7f0000007f80)=[{&(0x7f00000001c0)="de", 0x1}],
> > 0x1}, 0x0)
> > getsockopt$inet_sctp_SCTP_GET_PEER_ADDRS(r0, 0x84, 0x6c,
> > &(0x7f0000000000)={<r5=>0x0, 0x38,
> > "41925f90e4121fadc9c1296dd22ae19d0b1b0942e46fc79e2ecec1056b23199f0ca008915d8dba1b3896c154f2244bbe859fe3423a4b437a"},
> > &(0x7f0000000040)=0x40)
> >
> > Just need to check where the uninitializedness comes from.
> my only guess would be if we somehow copied an ipv4 address worth of data to the
> buffer (which contains an enum for both ipv4 and ipv6 addresses), and then
> copied an ipv6 address worth of data to userspace,

This seems to partially confirm this:

> Bytes 8-15 of 16 are uninitialized

Not 4 bytes are initialized, but still half of the ipv6 addr.


> but I don't yet see how that
> can happen.

The repro says "#{"threaded":true,"collide":true,"repeat":true,"procs":6".
So I would assume there is a race somewhere.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-29 18:51       ` Dmitry Vyukov
@ 2019-03-30  7:20         ` Xin Long
  2019-04-01  8:42           ` Alexander Potapenko
  0 siblings, 1 reply; 7+ messages in thread
From: Xin Long @ 2019-03-30  7:20 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Neil Horman, Alexander Potapenko, syzbot, David Miller, LKML,
	linux-sctp, Marcelo Ricardo Leitner, Networking, syzkaller-bugs,
	Vladislav Yasevich

On Sat, Mar 30, 2019 at 2:52 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Fri, Mar 29, 2019 at 7:31 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> > On Fri, Mar 29, 2019 at 06:35:40PM +0100, Alexander Potapenko wrote:
> > > On Fri, Mar 29, 2019 at 3:51 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > >
> > > > On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> > > > > git tree:       kmsan
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> > > > > compiler:       clang version 8.0.0 (trunk 350509)
> > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> > > > >
> > > > > IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> > > > > IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> > > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > > ==================================================================
> > > > > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > > > CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> > > > > 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+0x173/0x1d0 lib/dump_stack.c:113
> > > > >  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
> > > > >  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
> > > > >  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
> > > > >  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > > >  copy_to_user include/linux/uaccess.h:174 [inline]
> > > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
> > > > >  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
> > > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > > RIP: 0033:0x458209
> > > > > Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > > > RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > > > > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> > > > > RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> > > > > RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> > > > > R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> > > > > R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> > > > >
> > > > > Uninit was stored to memory at:
> > > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
> > > > >  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
> > > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > >
> > > > > Uninit was stored to memory at:
> > > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > > >  sctp_transport_init net/sctp/transport.c:61 [inline]
> > > > >  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
> > > > >  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
> > > > >  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
> > > > >  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
> > > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > > >  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
> > > > >  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
> > > > >  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
> > > > >  sk_backlog_rcv include/net/sock.h:936 [inline]
> > > > >  __release_sock+0x281/0x5f0 net/core/sock.c:2284
> > > > >  release_sock+0x99/0x2a0 net/core/sock.c:2800
> > > > >  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
> > > > >  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
> > > > >  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
> > > > >  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
> > > > >  sock_sendmsg_nosec net/socket.c:622 [inline]
> > > > >  sock_sendmsg net/socket.c:632 [inline]
> > > > >  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
> > > > >  __sys_sendmsg net/socket.c:2153 [inline]
> > > > >  __do_sys_sendmsg net/socket.c:2162 [inline]
> > > > >  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
> > > > >  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
> > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > >
> > > > > Local variable description: ----addr.i@sctp_process_init
> > > > > Variable was created at:
> > > > >  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
> > > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > > >
> > > > > Bytes 8-15 of 16 are uninitialized
> > > > > Memory access of size 16 starts at ffff88809511fc28
> > > > > Data copied to user address 0000000020000298
> > > > > ==================================================================
> > > > >
> > > > >
> > > > > ---
> > > > > 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.
> > > > > syzbot can test patches for this bug, for details see:
> > > > > https://goo.gl/tpsmEJ#testing-patches
> > > > >
> > > > >
> > > >
> > > >
> > > > Hmm, odd.  I see where we are doing the copy_to_user call in
> > > > getsockopt_peer_addrs, but the length we copy should always be equal to or less
> > > > than what was memcopied to the temp variable.  False positive?
> > > I'll take a closer look next week.
> > > The bug is reproducible with the following syzkaller program:
> > >
> > > r0 = socket$inet(0x2, 0x80001, 0x84)
> > > bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e20, @empty}, 0x10)
> > > sendmsg(r0, &(0x7f0000000100)={&(0x7f0000006000)=@in={0x2, 0x4e20,
> > > @loopback}, 0x80, &(0x7f0000007f80)=[{&(0x7f00000001c0)="de", 0x1}],
> > > 0x1}, 0x0)
> > > getsockopt$inet_sctp_SCTP_GET_PEER_ADDRS(r0, 0x84, 0x6c,
> > > &(0x7f0000000000)={<r5=>0x0, 0x38,
> > > "41925f90e4121fadc9c1296dd22ae19d0b1b0942e46fc79e2ecec1056b23199f0ca008915d8dba1b3896c154f2244bbe859fe3423a4b437a"},
> > > &(0x7f0000000040)=0x40)
> > >
> > > Just need to check where the uninitializedness comes from.
> > my only guess would be if we somehow copied an ipv4 address worth of data to the
> > buffer (which contains an enum for both ipv4 and ipv6 addresses), and then
> > copied an ipv6 address worth of data to userspace,
>
> This seems to partially confirm this:
>
> > Bytes 8-15 of 16 are uninitialized
From the call trace, Uninit memory was stored in 'addr' when processing
SCTP_PARAM_IPV4_ADDRESS in sctp_process_param() by
af->from_addr_param/sctp_v4_from_addr_param, in which
addr->v4.sin_family/port/sin_addr was set, but not addr->v4._pad,
which maches, 8-15 of 16 are uninitialized.

Then it went to sctp_transport_init(), and set the addr directly to
peer->ipaddr and added the new transport into asoc->peer.transport_addr_list.

When dumping peer_addrs in sctp_getsockopt_peer_addrs():

  memcpy(&temp, &from->ipaddr, sizeof(temp));
  copy_to_user(to, &temp, addrlen),

addrlen is sizeof(struct sockaddr_in), 16 bytes, but only the first 8
bytes were inited.

So we should fix it by setting addr->v4._pad in sctp_v4_addr_to_user as
sctp_v6_addr_to_user does:

@@ -600,6 +600,7 @@ static struct sock
*sctp_v4_create_accept_sk(struct sock *sk,
 static int sctp_v4_addr_to_user(struct sctp_sock *sp, union sctp_addr *addr)
 {
        /* No address mapping for V4 sockets */
+       memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero));
        return sizeof(struct sockaddr_in);
 }


>
> Not 4 bytes are initialized, but still half of the ipv6 addr.
>
>
> > but I don't yet see how that
> > can happen.
>
> The repro says "#{"threaded":true,"collide":true,"repeat":true,"procs":6".
> So I would assume there is a race somewhere.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: KMSAN: kernel-infoleak in sctp_getsockopt (3)
  2019-03-30  7:20         ` Xin Long
@ 2019-04-01  8:42           ` Alexander Potapenko
  0 siblings, 0 replies; 7+ messages in thread
From: Alexander Potapenko @ 2019-04-01  8:42 UTC (permalink / raw)
  To: Xin Long
  Cc: Dmitry Vyukov, Neil Horman, syzbot, David Miller, LKML,
	linux-sctp, Marcelo Ricardo Leitner, Networking, syzkaller-bugs,
	Vladislav Yasevich

On Sat, Mar 30, 2019 at 8:20 AM Xin Long <lucien.xin@gmail.com> wrote:
>
> On Sat, Mar 30, 2019 at 2:52 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >
> > On Fri, Mar 29, 2019 at 7:31 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > On Fri, Mar 29, 2019 at 06:35:40PM +0100, Alexander Potapenko wrote:
> > > > On Fri, Mar 29, 2019 at 3:51 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > On Thu, Mar 28, 2019 at 09:25:06AM -0700, syzbot wrote:
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following crash on:
> > > > > >
> > > > > > HEAD commit:    c10a026b kmsan: use __free_pages() in kmsan_iounmap_page_r..
> > > > > > git tree:       kmsan
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=107d3c7d200000
> > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=a5675814e8eae69e
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=86b5c7c236a22616a72f
> > > > > > compiler:       clang version 8.0.0 (trunk 350509)
> > > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1252834d200000
> > > > > >
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
> > > > > >
> > > > > > IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
> > > > > > IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
> > > > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > > > 8021q: adding VLAN 0 to HW filter on device batadv0
> > > > > > ==================================================================
> > > > > > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > > > > CPU: 0 PID: 10131 Comm: syz-executor.4 Not tainted 5.0.0+ #16
> > > > > > 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+0x173/0x1d0 lib/dump_stack.c:113
> > > > > >  kmsan_report+0x131/0x2a0 mm/kmsan/kmsan.c:636
> > > > > >  kmsan_internal_check_memory+0xaa1/0xbb0 mm/kmsan/kmsan.c:730
> > > > > >  kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:485
> > > > > >  _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
> > > > > >  copy_to_user include/linux/uaccess.h:174 [inline]
> > > > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
> > > > > >  sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
> > > > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > > > RIP: 0033:0x458209
> > > > > > Code: ad b8 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 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > > > > RSP: 002b:00007fdbef191c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
> > > > > > RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000458209
> > > > > > RDX: 000000000000006c RSI: 0000000000000084 RDI: 0000000000000004
> > > > > > RBP: 000000000073bf00 R08: 0000000020000300 R09: 0000000000000000
> > > > > > R10: 0000000020000280 R11: 0000000000000246 R12: 00007fdbef1926d4
> > > > > > R13: 00000000004c96c8 R14: 00000000004d0310 R15: 00000000ffffffff
> > > > > >
> > > > > > Uninit was stored to memory at:
> > > > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > > > >  sctp_getsockopt_peer_addrs net/sctp/socket.c:5906 [inline]
> > > > > >  sctp_getsockopt+0x16556/0x17f70 net/sctp/socket.c:7562
> > > > > >  sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2950
> > > > > >  __sys_getsockopt+0x489/0x550 net/socket.c:1938
> > > > > >  __do_sys_getsockopt net/socket.c:1949 [inline]
> > > > > >  __se_sys_getsockopt+0xe1/0x100 net/socket.c:1946
> > > > > >  __x64_sys_getsockopt+0x62/0x80 net/socket.c:1946
> > > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > > >
> > > > > > Uninit was stored to memory at:
> > > > > >  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:205 [inline]
> > > > > >  kmsan_save_stack mm/kmsan/kmsan.c:220 [inline]
> > > > > >  kmsan_internal_chain_origin+0x134/0x230 mm/kmsan/kmsan.c:426
> > > > > >  kmsan_memcpy_memmove_metadata+0xb5b/0xfe0 mm/kmsan/kmsan.c:304
> > > > > >  kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:324
> > > > > >  __msan_memcpy+0x58/0x70 mm/kmsan/kmsan_instr.c:139
> > > > > >  sctp_transport_init net/sctp/transport.c:61 [inline]
> > > > > >  sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
> > > > > >  sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
> > > > > >  sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
> > > > > >  sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
> > > > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > > > >  sctp_assoc_bh_rcv+0x65a/0xd80 net/sctp/associola.c:1074
> > > > > >  sctp_inq_push+0x300/0x420 net/sctp/inqueue.c:95
> > > > > >  sctp_backlog_rcv+0x20a/0xaf0 net/sctp/input.c:354
> > > > > >  sk_backlog_rcv include/net/sock.h:936 [inline]
> > > > > >  __release_sock+0x281/0x5f0 net/core/sock.c:2284
> > > > > >  release_sock+0x99/0x2a0 net/core/sock.c:2800
> > > > > >  sctp_wait_for_connect+0x3ee/0x860 net/sctp/socket.c:8751
> > > > > >  sctp_sendmsg_to_asoc+0x2167/0x21a0 net/sctp/socket.c:1967
> > > > > >  sctp_sendmsg+0x3fd7/0x6700 net/sctp/socket.c:2113
> > > > > >  inet_sendmsg+0x54a/0x720 net/ipv4/af_inet.c:798
> > > > > >  sock_sendmsg_nosec net/socket.c:622 [inline]
> > > > > >  sock_sendmsg net/socket.c:632 [inline]
> > > > > >  ___sys_sendmsg+0xdb9/0x11b0 net/socket.c:2115
> > > > > >  __sys_sendmsg net/socket.c:2153 [inline]
> > > > > >  __do_sys_sendmsg net/socket.c:2162 [inline]
> > > > > >  __se_sys_sendmsg+0x305/0x460 net/socket.c:2160
> > > > > >  __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2160
> > > > > >  do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> > > > > >  entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > > >
> > > > > > Local variable description: ----addr.i@sctp_process_init
> > > > > > Variable was created at:
> > > > > >  sctp_process_init+0xb5/0x3ed0 net/sctp/sm_make_chunk.c:2324
> > > > > >  sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > > > >  sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > > > >  sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > >  sctp_do_sm+0x3cfc/0x9af0 net/sctp/sm_sideeffect.c:1191
> > > > > >
> > > > > > Bytes 8-15 of 16 are uninitialized
> > > > > > Memory access of size 16 starts at ffff88809511fc28
> > > > > > Data copied to user address 0000000020000298
> > > > > > ==================================================================
> > > > > >
> > > > > >
> > > > > > ---
> > > > > > 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.
> > > > > > syzbot can test patches for this bug, for details see:
> > > > > > https://goo.gl/tpsmEJ#testing-patches
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > Hmm, odd.  I see where we are doing the copy_to_user call in
> > > > > getsockopt_peer_addrs, but the length we copy should always be equal to or less
> > > > > than what was memcopied to the temp variable.  False positive?
> > > > I'll take a closer look next week.
> > > > The bug is reproducible with the following syzkaller program:
> > > >
> > > > r0 = socket$inet(0x2, 0x80001, 0x84)
> > > > bind$inet(r0, &(0x7f0000000080)={0x2, 0x4e20, @empty}, 0x10)
> > > > sendmsg(r0, &(0x7f0000000100)={&(0x7f0000006000)=@in={0x2, 0x4e20,
> > > > @loopback}, 0x80, &(0x7f0000007f80)=[{&(0x7f00000001c0)="de", 0x1}],
> > > > 0x1}, 0x0)
> > > > getsockopt$inet_sctp_SCTP_GET_PEER_ADDRS(r0, 0x84, 0x6c,
> > > > &(0x7f0000000000)={<r5=>0x0, 0x38,
> > > > "41925f90e4121fadc9c1296dd22ae19d0b1b0942e46fc79e2ecec1056b23199f0ca008915d8dba1b3896c154f2244bbe859fe3423a4b437a"},
> > > > &(0x7f0000000040)=0x40)
> > > >
> > > > Just need to check where the uninitializedness comes from.
> > > my only guess would be if we somehow copied an ipv4 address worth of data to the
> > > buffer (which contains an enum for both ipv4 and ipv6 addresses), and then
> > > copied an ipv6 address worth of data to userspace,
> >
> > This seems to partially confirm this:
> >
> > > Bytes 8-15 of 16 are uninitialized
> From the call trace, Uninit memory was stored in 'addr' when processing
> SCTP_PARAM_IPV4_ADDRESS in sctp_process_param() by
> af->from_addr_param/sctp_v4_from_addr_param, in which
> addr->v4.sin_family/port/sin_addr was set, but not addr->v4._pad,
> which maches, 8-15 of 16 are uninitialized.
>
> Then it went to sctp_transport_init(), and set the addr directly to
> peer->ipaddr and added the new transport into asoc->peer.transport_addr_list.
Thanks for the analysis!
> When dumping peer_addrs in sctp_getsockopt_peer_addrs():
>
>   memcpy(&temp, &from->ipaddr, sizeof(temp));
>   copy_to_user(to, &temp, addrlen),
>
> addrlen is sizeof(struct sockaddr_in), 16 bytes, but only the first 8
> bytes were inited.
>
> So we should fix it by setting addr->v4._pad in sctp_v4_addr_to_user as
> sctp_v6_addr_to_user does:
>
> @@ -600,6 +600,7 @@ static struct sock
> *sctp_v4_create_accept_sk(struct sock *sk,
>  static int sctp_v4_addr_to_user(struct sctp_sock *sp, union sctp_addr *addr)
>  {
>         /* No address mapping for V4 sockets */
> +       memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero));
>         return sizeof(struct sockaddr_in);
>  }
I can confirm this is a valid fix.
>
> >
> > Not 4 bytes are initialized, but still half of the ipv6 addr.
> >
> >
> > > but I don't yet see how that
> > > can happen.
> >
> > The repro says "#{"threaded":true,"collide":true,"repeat":true,"procs":6".
> > So I would assume there is a race somewhere.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-04-01  8:43 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-28 16:25 KMSAN: kernel-infoleak in sctp_getsockopt (3) syzbot
2019-03-29 14:50 ` Neil Horman
2019-03-29 17:35   ` Alexander Potapenko
2019-03-29 18:30     ` Neil Horman
2019-03-29 18:51       ` Dmitry Vyukov
2019-03-30  7:20         ` Xin Long
2019-04-01  8:42           ` Alexander Potapenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).