CVE-2025-23145

Source
https://nvd.nist.gov/vuln/detail/CVE-2025-23145
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-23145.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2025-23145
Downstream
Related
Published
2025-05-01T13:15:50Z
Modified
2025-08-09T19:01:27Z
Summary
[none]
Details

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.

References

Affected packages