KMSAN: kernel-infoleak in put_cmsg

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 123906095e30 kmsan: introduce kmsan_interrupt_enter()/kmsa..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=166dafa0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=9adb4b567003cac781f0
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=164e4ab0400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15a41e40400000

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

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: kernel-infoleak in copy_to_user include/linux/uaccess.h:184
[inline]
BUG: KMSAN: kernel-infoleak in put_cmsg+0x5ef/0x860 net/core/scm.c:242
CPU: 0 PID: 4501 Comm: syz-executor128 Not tainted 4.17.0+ #9
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+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1219
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1261
copy_to_user include/linux/uaccess.h:184 [inline]
put_cmsg+0x5ef/0x860 net/core/scm.c:242
ip6_datagram_recv_specific_ctl+0x1cf3/0x1eb0 net/ipv6/datagram.c:719
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
sock_common_recvmsg+0x173/0x280 net/core/sock.c:3023
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4456b9
RSP: 002b:00007f5ce4b16da8 EFLAGS: 00000297 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 00000000004456b9
RDX: 0000000000000000 RSI: 00000000200004c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000297 R12: 00000000006dac20
R13: 0000000020000500 R14: 0100000000000000 R15: 0000000000000001

Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:297 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:689
__msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:464
ip6_datagram_recv_specific_ctl+0x1c3e/0x1eb0 net/ipv6/datagram.c:713
ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733
rawv6_recvmsg+0x10fb/0x1460 net/ipv6/raw.c:521
sock_common_recvmsg+0x173/0x280 net/core/sock.c:3023
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmsg net/socket.c:2328 [inline]
__do_sys_recvmsg net/socket.c:2338 [inline]
__se_sys_recvmsg net/socket.c:2335 [inline]
__x64_sys_recvmsg+0x325/0x460 net/socket.c:2335
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:192
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:318
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:325
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb35/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
__ip6_append_data+0x364d/0x4fb0 net/ipv6/ip6_output.c:1434
ip6_append_data+0x40e/0x6b0 net/ipv6/ip6_output.c:1597
rawv6_sendmsg+0x2756/0x4fc0 net/ipv6/raw.c:928
inet_sendmsg+0x3fc/0x760 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Bytes 2-3 of 24 are uninitialized
Memory access starts at ffff8801bde1f8a8
==================================================================


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

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Willem de Bruijn]

> Bytes 2-3 of 24 are uninitialized
> Memory access starts at ffff8801bde1f8a8

This socket requests IPV6_ORIGDSTADDR.

According to

> Uninit was stored to memory at:

> ip6_datagram_recv_specific_ctl+0x1c3e/0x1eb0 net/ipv6/datagram.c:713
> ip6_datagram_recv_ctl+0x41c/0x450 net/ipv6/datagram.c:733

It is reading two uninitialized bytes at line

sin6.sin6_port = ports[1];

But this access is after the check

__be16 *ports = (__be16 *) skb_transport_header(skb);

if (skb_transport_offset(skb) + 4 <= (int)skb->len) {

and the sent packet is 725B.

The socket was opened with SOCK_RAW and protocol NEXTHDR_DEST.

r0 = socket$inet6(0xa, 0x3, 0x3c)

so this is not a normal packet. Need to take a look at the contents.

[Willem de Bruijn]

The packet is generated in two stages with MSG_MORE. The first call
creates a zero-length packet, the second call appends the actual data.
Appends always happens in a frag (unless !SG). The existing test does
not catch this.

if (skb_transport_offset(skb) + 4 <= (int)skb->len) {

Something like the following would be needed to ensure that the bytes
lie in the head.

- __be16 *ports = (__be16 *) skb_transport_header(skb);
-
- if (skb_transport_offset(skb) + 4 <= (int)skb->len) {

+ int off = skb_transport_offset(skb) + 4;
+
+ if (off <= 0 || pskb_may_pull(skb, off)) {
+ __be16 *ports = (__be16 *) skb_transport_header(skb);

Here off can be negative, if the transport headers have already been
pulled, as in the case of UDP.

Casting the first four bytes to ports is really also not correct for
arbitrary protocols. This repro, for instance, has proto NEXTHDR_DEST.
This interface was perhaps not implemented with SOCK_RAW in mind;
either way, it's too late to exclude it now. But we can avoid the
__pskb_pull_tail and simply fail on odd packets like these:

- if (skb_transport_offset(skb) + 4 <= (int)skb->len) {
+ if (skb_transport_offset(skb) + 4 <= (int) skb_headlen(skb)) {

From a quick read, IPv4 appears susceptible to this, too. Will take a look.