CVE-2025-68227
NoneCVSS
—
EPSS
0.2%
Published
Dec 16, 2025
CISA due date
—
Cloudanix analysis
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
- Establish a TCP connection without MPTCP options to a server with MPTCP enabled
- Activate BPF sockmap or sockops that calls tcp_bpf_update_proto on the subflow
- Force subflow_ulp_fallback and mptcp_subflow_ops_undo_override
- 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
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel