In the Linux kernel, the following vulnerability has been resolved: mptcp: fix UaF in listener shutdown As reported by Christoph after having refactored the passive socket initialization, the mptcp listener shutdown path is prone to an UaF issue. BUG: KASAN: use-after-free in rawspinlockbh+0x73/0xe0 Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266 CPU: 1 PID: 1266 Comm: syz-executor731 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 kasancheckrange+0x14a/0x1a0 rawspinlockbh+0x73/0xe0 subflowerrorreport+0x6d/0x110 skerrorreport+0x3b/0x190 tcpdisconnect+0x138c/0x1aa0 inetchildforget+0x6f/0x2e0 inetcsklistenstop+0x209/0x1060 _mptcpclosessk+0x52d/0x610 mptcpdestroycommon+0x165/0x640 mptcpdestroy+0x13/0x80 _mptcpdestroysock+0xe7/0x270 _mptcpclose+0x70e/0x9b0 mptcpclose+0x2b/0x150 inetrelease+0xe9/0x1f0 _sockrelease+0xd2/0x280 sockclose+0x15/0x20 _fput+0x252/0xa20 taskworkrun+0x169/0x250 exittousermodeprepare+0x113/0x120 syscallexittousermode+0x1d/0x40 dosyscall64+0x48/0x90 entrySYSCALL64afterhwframe+0x72/0xdc The msk grace period can legitly expire in between the last reference count dropped in mptcpsubflowqueueclean() and the later eventual access in inetcsklisten_stop() After the previous patch we don't need anymore special-casing msk listener socket cleanup: the mptcp worker will process each of the unaccepted msk sockets. Just drop the now unnecessary code. Please note this commit depends on the two parent ones: mptcp: refactor passive socket initialization mptcp: use the workqueue to destroy unaccepted sockets