CVE-2023-53490

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix disconnect vs accept race<br /> <br /> Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in<br /> recvmsg()"), the mptcp protocol is still prone to a race between<br /> disconnect() (or shutdown) and accept.<br /> <br /> The root cause is that the mentioned commit checks the msk-level<br /> flag, but mptcp_stream_accept() does acquire the msk-level lock,<br /> as it can rely directly on the first subflow lock.<br /> <br /> As reported by Christoph than can lead to a race where an msk<br /> socket is accepted after that mptcp_subflow_queue_clean() releases<br /> the listener socket lock and just before it takes destructive<br /> actions leading to the following splat:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000012<br /> PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330<br /> Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89<br /> RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300<br /> RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a<br /> RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020<br /> R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880<br /> FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> do_accept+0x1ae/0x260 net/socket.c:1872<br /> __sys_accept4+0x9b/0x110 net/socket.c:1913<br /> __do_sys_accept4 net/socket.c:1954 [inline]<br /> __se_sys_accept4 net/socket.c:1951 [inline]<br /> __x64_sys_accept4+0x20/0x30 net/socket.c:1951<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Address the issue by temporary removing the pending request socket<br /> from the accept queue, so that racing accept() can&amp;#39;t touch them.<br /> <br /> After depleting the msk - the ssk still exists, as plain TCP sockets,<br /> re-insert them into the accept queue, so that later inet_csk_listen_stop()<br /> will complete the tcp socket disposal.