CVE-2025-23145

In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix NULL pointer in canacceptnew_subflow

When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcpcanacceptnewsubflow' because subflow_req->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/ip_input.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 'subflow_req->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 'subflow_req->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 own_req mpj branch where the code has been moved to.