Cloudanix VulnDB

CVE-2025-68227

None

CVSS

—

EPSS

0.2%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A networking bug in the Linux kernel could cause warning messages or unreliable connections when certain advanced socket features are used together, and updating the affected software packages resolves it.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability allows incorrect comparison of sk_prot during MPTCP fallback in subflow_syn_recv_sock when BPF sockmap has overridden the protocol, resulting in improper sk_socket->ops configuration and a kernel WARNING at mptcp_stream_accept.

Why it matters to the business

Systems relying on MPTCP combined with BPF sockmap may experience kernel warnings or degraded network stack reliability, increasing operational risk for high-availability network services until patched packages are deployed.

How an attack unfolds

An attacker triggers a TCP connection that forces MPTCP fallback while a BPF sockmap is active on the socket; the flawed sk_prot comparison in mptcp_fallback_tcp_ops then misconfigures socket operations, surfacing the warning during accept processing.

How to fix it

Upgrade all listed affected packages to the fixed versions: gitlab-cng-17.8 (Chainguard) to 17.8.2-r0 and equivalent Wolfi/Chainguard updates for gitaly-config, gitlab-base, gitlab-certificates, gitlab-cfssl-self-sign-scripts, gitlab-container-registry and related components through gitlab-geo-logcursor-scripts.

How to confirm the fix worked

Verify package versions match the fixed releases (17.8.2-r0) and confirm absence of the mptcp_stream_accept WARNING in kernel logs after applying updates; re-test MPTCP fallback scenarios under sockmap load.

Typical attack path

  1. Establish a TCP connection without MPTCP options to a server with MPTCP enabled
  2. Activate BPF sockmap or sockops that calls tcp_bpf_update_proto on the subflow
  3. Force subflow_ulp_fallback and mptcp_subflow_ops_undo_override
  4. Invoke accept path reaching mptcp_stream_accept which performs the incorrect sk_prot check

How to detect it

Search kernel logs and dmesg for the exact WARNING string referencing mptcp_stream_accept and net/mptcp/protocol.c:68; inspect call traces containing do_accept, __sys_accept4, and entry_SYSCALL_64 to identify prior occurrences.

  • WARNING: CPU:.*PID:.*at net/mptcp/protocol.c:68 mptcp_stream_accept
  • mptcp_stream_accept (net/mptcp/protocol.c:4005)
  • Call Trace:.*do_accept.*__sys_accept4.*__x64_sys_accept

What your security team should do

  • Immediately schedule upgrades to the 17.8.2-r0 fixed package versions across all affected GitLab container and config images
  • Monitor kernel logs for the mptcp_stream_accept WARNING until patches are deployed
  • Prioritize environments using both MPTCP and BPF sockmap for earliest remediation

The record

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 ]---

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.7.0 5.10.247
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.26.1.160000.2.7
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.26.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.26.1

Related vulnerabilities