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