In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in canacceptnewsubflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcpcanacceptnewsubflow' because subflowreq->msk is NULL. Call trace: mptcpcanacceptnewsubflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflowsynrecvsock (./net/mptcp/subflow.c:854) tcpcheckreq (./net/ipv4/tcpminisocks.c:863) tcpv4rcv (./net/ipv4/tcpipv4.c:2268) ipprotocoldeliverrcu (./net/ipv4/ipinput.c:207) iplocaldeliverfinish (./net/ipv4/ipinput.c:234) iplocaldeliver (./net/ipv4/ipinput.c:254) iprcvfinish (./net/ipv4/ipinput.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflowreq->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflowreq->msk' under the own_req == true
conditional. Note that the !msk check in subflowhmacvalid() can be dropped, because the same check already exists under the ownreq mpj branch where the code has been moved to.