CVE-2025-23145

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer in can_accept_new_subflow<br /> <br /> When testing valkey benchmark tool with MPTCP, the kernel panics in<br /> &amp;#39;mptcp_can_accept_new_subflow&amp;#39; because subflow_req-&gt;msk is NULL.<br /> <br /> Call trace:<br /> <br /> mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)<br /> subflow_syn_recv_sock (./net/mptcp/subflow.c:854)<br /> tcp_check_req (./net/ipv4/tcp_minisocks.c:863)<br /> tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)<br /> ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)<br /> ip_local_deliver_finish (./net/ipv4/ip_input.c:234)<br /> ip_local_deliver (./net/ipv4/ip_input.c:254)<br /> ip_rcv_finish (./net/ipv4/ip_input.c:449)<br /> ...<br /> <br /> According to the debug log, the same req received two SYN-ACK in a very<br /> short time, very likely because the client retransmits the syn ack due<br /> to multiple reasons.<br /> <br /> Even if the packets are transmitted with a relevant time interval, they<br /> can be processed by the server on different CPUs concurrently). The<br /> &amp;#39;subflow_req-&gt;msk&amp;#39; ownership is transferred to the subflow the first,<br /> and there will be a risk of a null pointer dereference here.<br /> <br /> This patch fixes this issue by moving the &amp;#39;subflow_req-&gt;msk&amp;#39; under the<br /> `own_req == true` conditional.<br /> <br /> Note that the !msk check in subflow_hmac_valid() can be dropped, because<br /> the same check already exists under the own_req mpj branch where the<br /> code has been moved to.