mptcp: error out earlier on disconnect

In the Linux kernel, the following vulnerability has been resolved:

mptcp: error out earlier on disconnect

Eric reported a division by zero splat in the MPTCP protocol:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI

CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted

6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0

Hardware name: Google Google Compute Engine/Google Compute Engine,

BIOS Google 09/13/2024

RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163

Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8

0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c

24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89

RSP: 0018:ffffc900041f7930 EFLAGS: 00010293

RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b

RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004

RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67

R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80

R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000

FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Call Trace:

<TASK>

__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493

mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]

mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289

inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885

sock_recvmsg_nosec net/socket.c:1051 [inline]

sock_recvmsg+0x1b2/0x250 net/socket.c:1073

__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265

__do_sys_recvfrom net/socket.c:2283 [inline]

__se_sys_recvfrom net/socket.c:2279 [inline]

__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279

do_syscall_x64 arch/x86/entry/common.c:52 [inline]

do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83

entry_SYSCALL_64_after_hwframe+0x77/0x7f

RIP: 0033:0x7feb5d857559

Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 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 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d

RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559

RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003

RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000

R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c

R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef

and provided a nice reproducer.

The root cause is the current bad handling of racing disconnect.

After the blamed commit below, sk_wait_data() can return (with

error) with the underlying socket disconnected and a zero rcv_mss.

Catch the error and return without performing any additional

operations on the current socket.