CVE-2025-68725

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not let BPF test infra emit invalid GSO types to stack<br /> <br /> Yinhao et al. reported that their fuzzer tool was able to trigger a<br /> skb_warn_bad_offload() from netif_skb_features() -&gt; gso_features_check().<br /> When a BPF program - triggered via BPF test infra - pushes the packet<br /> to the loopback device via bpf_clone_redirect() then mentioned offload<br /> warning can be seen. GSO-related features are then rightfully disabled.<br /> <br /> We get into this situation due to convert___skb_to_skb() setting<br /> gso_segs and gso_size but not gso_type. Technically, it makes sense<br /> that this warning triggers since the GSO properties are malformed due<br /> to the gso_type. Potentially, the gso_type could be marked non-trustworthy<br /> through setting it at least to SKB_GSO_DODGY without any other specific<br /> assumptions, but that also feels wrong given we should not go further<br /> into the GSO engine in the first place.<br /> <br /> The checks were added in 121d57af308d ("gso: validate gso_type in GSO<br /> handlers") because there were malicious (syzbot) senders that combine<br /> a protocol with a non-matching gso_type. If we would want to drop such<br /> packets, gso_features_check() currently only returns feature flags via<br /> netif_skb_features(), so one location for potentially dropping such skbs<br /> could be validate_xmit_unreadable_skb(), but then otoh it would be<br /> an additional check in the fast-path for a very corner case. Given<br /> bpf_clone_redirect() is the only place where BPF test infra could emit<br /> such packets, lets reject them right there.