CVE-2025-68725
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk6th percentile - higher than 6% of all known CVEs
Summary
A vulnerability was found in the Linux kernel's BPF test infrastructure that allowed generating invalid GSO (Generic Segmentation Offload) packets and sending them to the network stack. The issue occurred when a BPF program used bpf_clone_redirect() to redirect a packet to the loopback interface, triggering a skb_warn_bad_offload() warning and disabling GSO features.
Risk Assessment
The risk involves potential warnings and destabilization of the network stack due to malformed GSO packets. This could lead to reduced network performance or system errors.
Recommendation
Immediately update the Linux kernel to a version containing the fix that rejects invalid GSO packets in bpf_clone_redirect(). Monitor Linux distribution security advisories for the appropriate patch.
Original NVD description (English source)
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.