general protection fault in selinux_socket_recvmsg

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 051143e1 Merge tag 'apparmor-pr-2020-05-21' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1313f016100000
kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
dashboard link: https://syzkaller.appspot.com/bug?extid=c6bfc3db991edc918432
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13eeacba100000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167163e6100000

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

general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 7370 Comm: syz-executor283 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:selinux_socket_recvmsg+0x1e/0x40 security/selinux/hooks.c:4841
Code: e8 77 f9 1e fe 48 89 ef 5d eb b1 90 53 48 89 fb e8 67 f9 1e fe 48 8d 7b 18 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b 7b 18 be 02 00 00 00 5b e9 7d fc ff ff e8
RSP: 0018:ffffc900019d7a58 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
RDX: 0000000000000003 RSI: ffffffff83543bb9 RDI: 0000000000000018
RBP: dffffc0000000000 R08: ffff88809f45a180 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
R13: ffffc900019d7d78 R14: 0000000000001000 R15: 0000000040000000
FS: 00007f5ffb311700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5ffb2efe78 CR3: 00000000a33c1000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
security_socket_recvmsg+0x78/0xc0 security/security.c:2070
sock_recvmsg+0x47/0x110 net/socket.c:902
mptcp_recvmsg+0xb3b/0xd90 net/mptcp/protocol.c:891
inet_recvmsg+0x121/0x5d0 net/ipv4/af_inet.c:838
sock_recvmsg_nosec net/socket.c:886 [inline]
sock_recvmsg net/socket.c:904 [inline]
sock_recvmsg+0xca/0x110 net/socket.c:900
__sys_recvfrom+0x1c5/0x2f0 net/socket.c:2057
__do_sys_recvfrom net/socket.c:2075 [inline]
__se_sys_recvfrom net/socket.c:2071 [inline]
__x64_sys_recvfrom+0xdd/0x1b0 net/socket.c:2071
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x448ef9
Code: e8 cc 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 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 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f5ffb310da8 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
RAX: ffffffffffffffda RBX: 00000000006dec28 RCX: 0000000000448ef9
RDX: 0000000000001000 RSI: 00000000200004c0 RDI: 0000000000000003
RBP: 00000000006dec20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000040000000 R11: 0000000000000246 R12: 00000000006dec2c
R13: 00007ffc3a001ccf R14: 00007f5ffb3119c0 R15: 00000000006dec2c
Modules linked in:
---[ end trace 60e1f3eb5a5b83ce ]---
RIP: 0010:selinux_socket_recvmsg+0x1e/0x40 security/selinux/hooks.c:4841
Code: e8 77 f9 1e fe 48 89 ef 5d eb b1 90 53 48 89 fb e8 67 f9 1e fe 48 8d 7b 18 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b 7b 18 be 02 00 00 00 5b e9 7d fc ff ff e8
RSP: 0018:ffffc900019d7a58 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
RDX: 0000000000000003 RSI: ffffffff83543bb9 RDI: 0000000000000018
RBP: dffffc0000000000 R08: ffff88809f45a180 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
R13: ffffc900019d7d78 R14: 0000000000001000 R15: 0000000040000000
FS: 00007f5ffb311700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5ffb2efe78 CR3: 00000000a33c1000 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 syzk...@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

[Ondrej Mosnacek]

On Sat, May 23, 2020 at 9:14 AM syzbot
<syzbot+c6bfc3...@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 051143e1 Merge tag 'apparmor-pr-2020-05-21' of git://git.k..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1313f016100000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
> dashboard link: https://syzkaller.appspot.com/bug?extid=c6bfc3db991edc918432
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13eeacba100000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167163e6100000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c6bfc3...@syzkaller.appspotmail.com
>
> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
> CPU: 0 PID: 7370 Comm: syz-executor283 Not tainted 5.7.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:selinux_socket_recvmsg+0x1e/0x40 security/selinux/hooks.c:4841

OK, this is obviously not a SELinux bug - the hook just gets sock ==
NULL from the net stack, which is just plain wrong...

> Code: e8 77 f9 1e fe 48 89 ef 5d eb b1 90 53 48 89 fb e8 67 f9 1e fe 48 8d 7b 18 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b 7b 18 be 02 00 00 00 5b e9 7d fc ff ff e8
> RSP: 0018:ffffc900019d7a58 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000040000000
> RDX: 0000000000000003 RSI: ffffffff83543bb9 RDI: 0000000000000018
> RBP: dffffc0000000000 R08: ffff88809f45a180 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
> R13: ffffc900019d7d78 R14: 0000000000001000 R15: 0000000040000000
> FS: 00007f5ffb311700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f5ffb2efe78 CR3: 00000000a33c1000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> security_socket_recvmsg+0x78/0xc0 security/security.c:2070
> sock_recvmsg+0x47/0x110 net/socket.c:902
> mptcp_recvmsg+0xb3b/0xd90 net/mptcp/protocol.c:891

...but this function looks suspicious. If the "unlikely(ssock)" check
at [1] fails, then we continue in the rest of the function with ssock
== NULL. However, when the "unlikely(__mptcp_tcp_fallback(msk))" check
at [2] succeeds, we jump to the "fallback" label, where it is assumed
that ssock != NULL. That seems like an obvious bug to me and I bet
that's what causes the crash.

If I understand the code correctly, the fix should be just to change
this at [2]:
- if (unlikely(__mptcp_tcp_fallback(msk)))
+ if (unlikely(ssock = __mptcp_tcp_fallback(msk)))

@MPTCP folks, can you have a look?

[1] https://elixir.bootlin.com/linux/v5.7-rc6/source/net/mptcp/protocol.c#L886
[2] https://elixir.bootlin.com/linux/v5.7-rc6/source/net/mptcp/protocol.c#L957

--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

[Tetsuo Handa]

On 2020/05/23 21:16, Ondrej Mosnacek wrote:
> If I understand the code correctly, the fix should be just to change
> this at [2]:
> - if (unlikely(__mptcp_tcp_fallback(msk)))
> + if (unlikely(ssock = __mptcp_tcp_fallback(msk)))

You can ask syzbot to test your patch using "#syz test:".

If syzbot were using CONFIG_DYNAMIC_DEBUG=y ,
this NULL pointer dereference would have been already reported at

pr_debug("fallback-read subflow=%p",
mptcp_subflow_ctx(ssock->sk));

as a mptcp bug. Since syzbot is using fixed console loglevel, KERN_DEBUG
messages won't be printed to consoles. Thus, setting CONFIG_DYNAMIC_DEBUG=y
would help finding bugs in pr_debug().

[Tetsuo Handa]

Oops, dynamic_pr_debug() is disabled by default. Then, unconditionally converting
pr_debug() into printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) will be the better.
I'll propose a config option selected by CONFIG_TWIST_FOR_SYZKALLER_TESTING=y if
you want syzbot to execute pr_debug() calls.

[syzbot]

syzbot has bisected this bug to:

commit 263e1201a2c324b60b15ecda5de9ebf1e7293e31
Author: Paolo Abeni <pab...@redhat.com>
Date: Thu Apr 30 13:01:51 2020 +0000

mptcp: consolidate synack processing.

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12a5254a100000
start commit: 051143e1 Merge tag 'apparmor-pr-2020-05-21' of git://git.k..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=11a5254a100000
console output: https://syzkaller.appspot.com/x/log.txt?x=16a5254a100000

kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
dashboard link: https://syzkaller.appspot.com/bug?extid=c6bfc3db991edc918432

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13eeacba100000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167163e6100000

Reported-by: syzbot+c6bfc3...@syzkaller.appspotmail.com
Fixes: 263e1201a2c3 ("mptcp: consolidate synack processing.")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Ondrej Mosnacek]

On Sun, May 24, 2020 at 1:00 PM Tetsuo Handa
<penguin...@i-love.sakura.ne.jp> wrote:
> On 2020/05/23 21:16, Ondrej Mosnacek wrote:
> > If I understand the code correctly, the fix should be just to change
> > this at [2]:
> > - if (unlikely(__mptcp_tcp_fallback(msk)))
> > + if (unlikely(ssock = __mptcp_tcp_fallback(msk)))
>
> You can ask syzbot to test your patch using "#syz test:".

Yes, I know, I just didn't feel like going all the way on a Saturday
:) Besides, even if it makes the NULL pointer deref o away, it doesn't
necessarily mean that it is the right fix. I'm not familiar enough
with this code to dare submitting a formal patch. I trust that MPTCP
developers will do a better job at it than me :)

>
> If syzbot were using CONFIG_DYNAMIC_DEBUG=y ,
> this NULL pointer dereference would have been already reported at
>
> pr_debug("fallback-read subflow=%p",
> mptcp_subflow_ctx(ssock->sk));
>
> as a mptcp bug. Since syzbot is using fixed console loglevel, KERN_DEBUG
> messages won't be printed to consoles. Thus, setting CONFIG_DYNAMIC_DEBUG=y
> would help finding bugs in pr_debug().

(I'll react to this as a reply to your patch.)

[Paolo Abeni]

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master

---
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 1f52a0fa31ed..69b66423305b 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -954,7 +954,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,

pr_debug("block timeout %ld", timeo);
mptcp_wait_data(sk, &timeo);
- if (unlikely(__mptcp_tcp_fallback(msk)))
+ ssock = __mptcp_tcp_fallback(msk);
+ if (unlikely(ssock))
goto fallback;
}

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger crash:

Reported-and-tested-by: syzbot+c6bfc3...@syzkaller.appspotmail.com

Tested on:

commit: 98790bba Merge tag 'efi-urgent-2020-05-24' of git://git.ke..
git tree: net

kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace
dashboard link: https://syzkaller.appspot.com/bug?extid=c6bfc3db991edc918432

compiler: gcc (GCC) 9.0.0 20181231 (experimental)

patch: https://syzkaller.appspot.com/x/patch.diff?x=127e6016100000

Note: testing is done by a robot and is best-effort only.