CVE-2025-68227 Affecting rv package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS9-RV-14483195
- published18 Dec 2025
- disclosed16 Dec 2025
Introduced: 16 Dec 2025
CVE-2025-68227 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 rv.
NVD Description
Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
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 sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot '''
When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() '''
Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_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) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
References
- https://access.redhat.com/security/cve/CVE-2025-68227
- https://git.kernel.org/stable/c/037cc50589643342d69185b663ecf9d26cce91e8
- https://git.kernel.org/stable/c/1a0d5c74af9b6ba9ffdf1172de5a1a6df5922a00
- https://git.kernel.org/stable/c/344974ea1a3ca30e4920687b0091bda4438cebdb
- https://git.kernel.org/stable/c/7ee8f015eb47907745e2070184a8ab1e442ac3c4
- https://git.kernel.org/stable/c/92c4092fe012ecdfa5fb05d394f1c1d8f91ad81c
- https://git.kernel.org/stable/c/9b1980b6f23fa30bf12add19f37c7458625099eb
- https://git.kernel.org/stable/c/c77b3b79a92e3345aa1ee296180d1af4e7031f8f