WARNING: bad unlock balance in mptcp_poll

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: ae46d2aa mm/gup: Let __get_user_pages_locked() return -EIN..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14fef69fe00000
kernel config: https://syzkaller.appspot.com/x/.config?x=ca75979eeebf06c2
dashboard link: https://syzkaller.appspot.com/bug?extid=e56606435b7bfeea8cf5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111ccd2be00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=162b0a77e00000

The bug was bisected to:

commit 59832e246515ab6a4f5aa878073e6f415aa35166
Author: Florian Westphal <f...@strlen.de>
Date: Thu Apr 2 11:44:52 2020 +0000

mptcp: subflow: check parent mptcp socket on subflow state change

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14c1f69fe00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=16c1f69fe00000
console output: https://syzkaller.appspot.com/x/log.txt?x=12c1f69fe00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e56606...@syzkaller.appspotmail.com
Fixes: 59832e246515 ("mptcp: subflow: check parent mptcp socket on subflow state change")

=====================================
WARNING: bad unlock balance detected!
5.6.0-syzkaller #0 Not tainted
-------------------------------------
syz-executor473/7733 is trying to release lock (sk_lock-AF_INET6) at:
[<ffffffff87c51839>] mptcp_poll+0xb9/0x530 net/mptcp/protocol.c:1856
but there are no more locks to release!

other info that might help us debug this:
1 lock held by syz-executor473/7733:
#0: ffff88808fe2f0a0 (slock-AF_INET6){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:358 [inline]
#0: ffff88808fe2f0a0 (slock-AF_INET6){+...}-{2:2}, at: release_sock+0x1b/0x1b0 net/core/sock.c:2974

stack backtrace:
CPU: 0 PID: 7733 Comm: syz-executor473 Not tainted 5.6.0-syzkaller #0
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+0x188/0x20d lib/dump_stack.c:118
__lock_release kernel/locking/lockdep.c:4633 [inline]
lock_release+0x586/0x800 kernel/locking/lockdep.c:4941
sock_release_ownership include/net/sock.h:1539 [inline]
release_sock+0x177/0x1b0 net/core/sock.c:2984
mptcp_poll+0xb9/0x530 net/mptcp/protocol.c:1856
sock_poll+0x15c/0x470 net/socket.c:1271
vfs_poll include/linux/poll.h:90 [inline]
do_pollfd fs/select.c:859 [inline]
do_poll fs/select.c:907 [inline]
do_sys_poll+0x63c/0xdd0 fs/select.c:1001
__do_sys_ppoll fs/select.c:1101 [inline]
__se_sys_ppoll fs/select.c:1081 [inline]
__x64_sys_ppoll+0x210/0x280 fs/select.c:1081
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x441219
Code: e8 fc ab 02 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 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff9deb18e8 EFLAGS: 00000246 ORIG_RAX: 000000000000010f
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441219
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000020000080
RBP: 000000000000f233 R08: 3f00000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000402040
R13: 00000000004020d0 R14: 0000000000000000 R15: 0000000000000000


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

[Florian Westphal]

mptcp_connect/28740 is trying to release lock (sk_lock-AF_INET) at:
[<ffffffff82c15869>] mptcp_poll+0xb9/0x550

but there are no more locks to release!

Call Trace:
lock_release+0x50f/0x750
release_sock+0x171/0x1b0
mptcp_poll+0xb9/0x550
sock_poll+0x157/0x470
? get_net_ns+0xb0/0xb0
do_sys_poll+0x63c/0xdd0

Problem is that __mptcp_tcp_fallback() releases the mptcp socket lock,
but after recent change it doesn't do this in all of its return paths.

To fix this, remove the unlock from __mptcp_tcp_fallback() and
always do the unlock in the caller.

Also add a small comment as to why we have this
__mptcp_needs_tcp_fallback().

Fixes: 0b4f33def7bbde ("mptcp: fix tcp fallback crash")
Reported-by: syzbot+e56606...@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal <f...@strlen.de>
---
NB: Reproducer did not trigger for me, so i can't be 100% sure,
but looking at the 'Fixes' commit the change to
__mptcp_needs_tcp_fallback was broken.

net/mptcp/protocol.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 72f3176dc924..559253be6a21 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -97,12 +97,7 @@ static struct socket *__mptcp_tcp_fallback(struct mptcp_sock *msk)
if (likely(!__mptcp_needs_tcp_fallback(msk)))
return NULL;

- if (msk->subflow) {
- release_sock((struct sock *)msk);
- return msk->subflow;
- }
-
- return NULL;
+ return msk->subflow;
}

static bool __mptcp_can_create_subflow(const struct mptcp_sock *msk)
@@ -734,9 +729,10 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
goto out;
}

+fallback:
ssock = __mptcp_tcp_fallback(msk);
if (unlikely(ssock)) {
-fallback:
+ release_sock(sk);
pr_debug("fallback passthrough");
ret = sock_sendmsg(ssock, msg);
return ret >= 0 ? ret + copied : (copied ? copied : ret);
@@ -778,8 +774,14 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
if (ret < 0)
break;
if (ret == 0 && unlikely(__mptcp_needs_tcp_fallback(msk))) {
+ /* Can happen for passive sockets:
+ * 3WHS negotiated MPTCP, but first packet after is
+ * plain TCP (e.g. due to middlebox filtering unknown
+ * options).
+ *
+ * Fall back to TCP.
+ */
release_sock(ssk);
- ssock = __mptcp_tcp_fallback(msk);
goto fallback;
}

@@ -892,6 +894,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
ssock = __mptcp_tcp_fallback(msk);
if (unlikely(ssock)) {
fallback:
+ release_sock(sk);
pr_debug("fallback-read subflow=%p",
mptcp_subflow_ctx(ssock->sk));
copied = sock_recvmsg(ssock, msg, flags);
@@ -1476,12 +1479,11 @@ static int mptcp_setsockopt(struct sock *sk, int level, int optname,
*/
lock_sock(sk);
ssock = __mptcp_tcp_fallback(msk);
+ release_sock(sk);
if (ssock)
return tcp_setsockopt(ssock->sk, level, optname, optval,
optlen);

- release_sock(sk);
-
return -EOPNOTSUPP;
}

@@ -1501,12 +1503,11 @@ static int mptcp_getsockopt(struct sock *sk, int level, int optname,
*/
lock_sock(sk);
ssock = __mptcp_tcp_fallback(msk);
+ release_sock(sk);
if (ssock)
return tcp_getsockopt(ssock->sk, level, optname, optval,
option);

- release_sock(sk);
-
return -EOPNOTSUPP;
}

--
2.24.1

[David Miller]

From: Florian Westphal <f...@strlen.de>
Date: Sat, 11 Apr 2020 21:05:01 +0200

> mptcp_connect/28740 is trying to release lock (sk_lock-AF_INET) at:
> [<ffffffff82c15869>] mptcp_poll+0xb9/0x550
> but there are no more locks to release!
> Call Trace:
> lock_release+0x50f/0x750
> release_sock+0x171/0x1b0
> mptcp_poll+0xb9/0x550
> sock_poll+0x157/0x470
> ? get_net_ns+0xb0/0xb0
> do_sys_poll+0x63c/0xdd0
>
> Problem is that __mptcp_tcp_fallback() releases the mptcp socket lock,
> but after recent change it doesn't do this in all of its return paths.
>
> To fix this, remove the unlock from __mptcp_tcp_fallback() and
> always do the unlock in the caller.
>
> Also add a small comment as to why we have this
> __mptcp_needs_tcp_fallback().
>
> Fixes: 0b4f33def7bbde ("mptcp: fix tcp fallback crash")
> Reported-by: syzbot+e56606...@syzkaller.appspotmail.com
> Signed-off-by: Florian Westphal <f...@strlen.de>
> ---
> NB: Reproducer did not trigger for me, so i can't be 100% sure,
> but looking at the 'Fixes' commit the change to
> __mptcp_needs_tcp_fallback was broken.

Applied, thanks Florian.