Cloudanix VulnDB

CVE-2025-68725

Medium · 5.5

CVSS

5.5

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in the Linux kernel's testing tools can send malformed network packets that trigger warnings and slow down network handling on affected machines.

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

What it actually does

The vulnerability allows the BPF test infrastructure to invoke bpf_clone_redirect() with packets that have gso_segs and gso_size set but gso_type unset, producing malformed GSO metadata that reaches gso_features_check() and triggers skb_warn_bad_offload(), disabling offload features.

Why it matters to the business

Systems running affected Linux kernels or dependent products such as tigera-operator may experience spurious network offload warnings and degraded packet-processing performance during BPF test operations; the issue is present in widely deployed kernel trees with hundreds of downstream dependents.

How an attack unfolds

An attacker with local access loads a BPF program via the test infrastructure that calls bpf_clone_redirect() to the loopback device; the missing gso_type field causes the kernel to emit an invalid GSO packet, triggering the warning path and disabling GSO features for subsequent traffic.

How to fix it

Upgrade to a fixed kernel containing commit bb7902ed7d7f6d6a7c6c4dc25410d6127ce1085f or install tigera-operator-1.28.15-r18; rebuild and reboot any affected systems; disable unneeded BPF test infrastructure where feasible until patches are applied.

How to confirm the fix worked

Verify the running kernel contains commit bb7902ed7d7f6d6a7c6c4dc25410d6127ce1085f or later; confirm tigera-operator reports version 1.28.15-r18 or newer; reproduce a BPF redirect test and ensure no skb_warn_bad_offload() messages appear.

Typical attack path

  1. Obtain local access to a system running an affected kernel
  2. Load a BPF program through the test infrastructure that performs bpf_clone_redirect()
  3. Send crafted packets that set gso_segs/gso_size without gso_type
  4. Observe skb_warn_bad_offload() and resulting GSO feature disablement

How to detect it

Search kernel logs and dmesg for skb_warn_bad_offload() messages originating from netif_skb_features(); correlate with processes invoking BPF test programs or bpf_clone_redirect() on loopback.

  • skb_warn_bad_offload
  • gso_features_check
  • convert___skb_to_skb

What your security team should do

  • Apply the listed fixed versions immediately on all affected hosts
  • Prioritize patching systems that expose BPF test interfaces to untrusted users
  • Monitor kernel logs for skb_warn_bad_offload() entries as an interim detection measure
  • Review and restrict use of bpf_clone_redirect() in test environments

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 5.6.0 5.10.249
Linux Kernel 5.6.0 6.18.2
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
openSUSE:Tumbleweed kernel-source 0 6.18.5-1.1
openSUSE:Tumbleweed kernel-source-longterm 0 6.18.16-1.1

Related vulnerabilities