CVE-2025-68725

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 skbwarnbadoffload() from netifskbfeatures() -> gsofeaturescheck(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpfclone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled.

We get into this situation due to convert__skbtoskb() setting gsosegs and gsosize but not gsotype. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gsotype. Potentially, the gsotype could be marked non-trustworthy through setting it at least to SKBGSODODGY 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 gsotype in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gsotype. If we would want to drop such packets, gsofeaturescheck() currently only returns feature flags via netifskbfeatures(), so one location for potentially dropping such skbs could be validatexmitunreadableskb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpfclone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.