CVE-2023-53072

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: use the workqueue to destroy unaccepted sockets<br /> <br /> Christoph reported a UaF at token lookup time after having<br /> refactored the passive socket initialization part:<br /> <br /> BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260<br /> Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198<br /> <br /> CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0x91<br /> print_report+0x16a/0x46f<br /> kasan_report+0xad/0x130<br /> __token_bucket_busy+0x253/0x260<br /> mptcp_token_new_connect+0x13d/0x490<br /> mptcp_connect+0x4ed/0x860<br /> __inet_stream_connect+0x80e/0xd90<br /> tcp_sendmsg_fastopen+0x3ce/0x710<br /> mptcp_sendmsg+0xff1/0x1a20<br /> inet_sendmsg+0x11d/0x140<br /> __sys_sendto+0x405/0x490<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> We need to properly clean-up all the paired MPTCP-level<br /> resources and be sure to release the msk last, even when<br /> the unaccepted subflow is destroyed by the TCP internals<br /> via inet_child_forget().<br /> <br /> We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,<br /> explicitly checking that for the critical scenario: the<br /> closed subflow is the MPC one, the msk is not accepted and<br /> eventually going through full cleanup.<br /> <br /> With such change, __mptcp_destroy_sock() is always called<br /> on msk sockets, even on accepted ones. We don&amp;#39;t need anymore<br /> to transiently drop one sk reference at msk clone time.<br /> <br /> Please note this commit depends on the parent one:<br /> <br /> mptcp: refactor passive socket initialization