Linux Kernel
CVE-2025-68725
MEDIUM
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local access with low privileges (CAP_BPF or unprivileged BPF) required to load BPF programs; impact is pure availability via GSO offload disruption with no data exposure or integrity effect.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
2DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.
AnalysisAI
BPF test infrastructure in the Linux kernel allows a local user with BPF program execution privileges to emit packets with malformed GSO (Generic Segmentation Offload) metadata to the network stack via bpf_clone_redirect(), triggering skb_warn_bad_offload() and disabling GSO-related offload features - a denial-of-service condition. The root cause is convert___skb_to_skb() populating gso_segs and gso_size without a corresponding gso_type, producing an internally inconsistent socket buffer that fails GSO validation in netif_skb_features(). No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified; the issue was originally surfaced through fuzzing by Yinhao et al. Patches across six stable kernel branches have been released.
Technical ContextAI
The vulnerability exists within the Linux kernel BPF subsystem's test infrastructure, specifically in the convert___skb_to_skb() function, which prepares a socket buffer (skb) for use by BPF programs. When bpf_clone_redirect() is called from a BPF test infra context, it can redirect packets to network interfaces (e.g., loopback) carrying incomplete GSO metadata: gso_segs and gso_size are set, but gso_type is left uninitialized or zero. When the packet traverses the transmit path, netif_skb_features() invokes gso_features_check() - a validation layer added by kernel commit 121d57af308d specifically to reject protocol/gso_type mismatches that syzbot had previously been generating maliciously. The type mismatch triggers skb_warn_bad_offload() and causes the kernel to strip GSO-related offload capabilities from that code path. Affected CPE is cpe:2.3:o:linux:linux_kernel:* across multiple stable series. No CWE is assigned by NVD, but the root cause aligns with CWE-20 (Improper Input Validation) applied to internal kernel state: the BPF test infra does not validate or set gso_type before forwarding to the transmit stack.
RemediationAI
Apply the upstream Linux kernel stable patches: commits 04a899573fb8, 0f3a60869ca2, 768376ece703, 8670b53b8ee9, bb7902ed7d7f, and e0ffb64a2d72 are available at https://git.kernel.org/stable/ and cover multiple stable kernel branches. Distribution users (RHEL, Ubuntu, Debian, SUSE, etc.) should apply kernel updates once their distribution backports the fix to their supported kernel series - monitor distribution security advisories for precise update versions, as the exact patched release version is not independently confirmed from the available data beyond the upstream commits. Siemens customers should consult SSA-019113 directly for product-specific remediation timelines. As a compensating control where immediate patching is not feasible, set sysctl kernel.unprivileged_bpf_disabled=1 to restrict BPF program loading to privileged users only (CAP_BPF or CAP_NET_ADMIN), which eliminates the unprivileged exploitation path; note this may break eBPF-based observability tools (e.g., some BCC or bpftrace use cases) that rely on unprivileged BPF. For container environments, ensure BPF capabilities (CAP_BPF, CAP_NET_ADMIN) are not granted to untrusted workloads via container runtime policy.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today