WARNING: bad unlock balance in mptcp_poll

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 <fw@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+e56606435b7bfeea8cf5@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 syzkaller@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

[PATCH net] mptcp: fix double-unlock in mptcp_poll

[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+e56606435b7bfeea8cf5@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal <fw@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

Re: [PATCH net] mptcp: fix double-unlock in mptcp_poll

[David Miller]

From: Florian Westphal <fw@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+e56606435b7bfeea8cf5@syzkaller.appspotmail.com
> Signed-off-by: Florian Westphal <fw@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.