CVE-2024-53123

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: error out earlier on disconnect<br /> <br /> Eric reported a division by zero splat in the MPTCP protocol:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted<br /> 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine,<br /> BIOS Google 09/13/2024<br /> RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163<br /> Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8<br /> 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c<br /> 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89<br /> RSP: 0018:ffffc900041f7930 EFLAGS: 00010293<br /> RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b<br /> RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004<br /> RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67<br /> R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80<br /> R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000<br /> FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493<br /> mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]<br /> mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289<br /> inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885<br /> sock_recvmsg_nosec net/socket.c:1051 [inline]<br /> sock_recvmsg+0x1b2/0x250 net/socket.c:1073<br /> __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265<br /> __do_sys_recvfrom net/socket.c:2283 [inline]<br /> __se_sys_recvfrom net/socket.c:2279 [inline]<br /> __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7feb5d857559<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48<br /> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d<br /> 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d<br /> RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559<br /> RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000<br /> R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c<br /> R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef<br /> <br /> and provided a nice reproducer.<br /> <br /> The root cause is the current bad handling of racing disconnect.<br /> After the blamed commit below, sk_wait_data() can return (with<br /> error) with the underlying socket disconnected and a zero rcv_mss.<br /> <br /> Catch the error and return without performing any additional<br /> operations on the current socket.