CVE-2025-68227

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

mptcp: Fix proto fallback detection with BPF

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the skprot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcprcvstateprocess() synrecvsock()/subflowsynrecvsock() tcpinittransfer(BPFSOCKOPSPASSIVEESTABLISHEDCB) bpfskopsestablished <== sockops bpfsockmapupdate(sk) <== call bpf helper tcpbpfupdateproto() <== update sk_prot '''

When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflowsynrecvsock() performs a fallback on the subflow, replacing the subflow sk's skprot with the native skprot. ''' subflowsynrecvsock() subflowulpfallback() subflowdropctx() mptcpsubflowopsundooverride() '''

Then, this subflow can be normally used by sockmap, which replaces the native skprot with sockmap's custom skprot. The issue occurs when the user executes accept::mptcpstreamaccept::mptcpfallbacktcpops(). Here, it uses sk->skprot to compare with the native skprot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sksocket->ops.

This fix uses the more generic sk_family for the comparison instead.

Additionally, this also prevents a WARNING from occurring:

result from ./scripts/decodestacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcpstream_accept \ (net/mptcp/protocol.c:4005) Modules linked in: ...

PKRU: 55555554 Call Trace: <TASK> do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64sysaccept (net/socket.c:2067) x64syscall (arch/x86/entry/syscall64.c:41) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f87ac92b83d

---[ end trace 0000000000000000 ]---