[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id:
<176099220626.401229.10029182117746939973.git-patchwork-notify@kernel.org>
Date: Mon, 20 Oct 2025 20:30:06 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Daniel Borkmann <daniel@...earbox.net>
Cc: martin.lau@...ux.dev, kuba@...nel.org, bpf@...r.kernel.org,
netdev@...r.kernel.org, dddddd@...t.edu.cn, M202472210@...t.edu.cn,
dzm91@...t.edu.cn, willemb@...gle.com, sdf@...ichev.me
Subject: Re: [PATCH bpf] bpf: Do not let BPF test infra emit invalid GSO types
to
stack
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Martin KaFai Lau <martin.lau@...nel.org>:
On Mon, 20 Oct 2025 09:54:41 +0200 you wrote:
> 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.
>
> [...]
Here is the summary with links:
- [bpf] bpf: Do not let BPF test infra emit invalid GSO types to stack
https://git.kernel.org/bpf/bpf-next/c/04a899573fb8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Powered by blists - more mailing lists