On 02/28/2018 04:56 PM, David Miller wrote: > From: Daniel Axtens <d...@axtens.net> > Date: Wed, 28 Feb 2018 00:04:06 +1100 > >> An audit of users of gso_size reveals that an eBPF tc action on a >> veth pair can be passed an SCTP GSO skb, which has gso_size of >> GSO_BY_FRAGS. >> >> If that action calls bpf_skb_change_proto(), bpf_skb_net_grow() >> or bpf_skb_net_shrink(), the gso_size will be unconditionally >> incremented or decremented to some nonsense value. >> >> Add helpers that WARN if attempting to change a gso_size of a >> GSO_BY_FRAGS skb (and leave the value unchanged). >> >> Signed-off-by: Daniel Axtens <d...@axtens.net> > > We can't really do this. > > It means that a user loaded eBPF program can trigger logs full of > warnings merely by using this eBPF helper and generating GSO'd SCTP > traffic. > > Daniel and Alexei, this is a serious problem. The eBPF helpers > mentioned here cannot handle SCTP GSO packets properly, and in fact > corrupt them if they adjust the gso_size. > > SCTP GSO packets use the GSO_BY_FRAGS scheme and cannot be treated > the same way we treat normal GSO packets.
Thanks for Cc, I would have missed it. This patch in combination with patch 6/6 seems okay since we reject it in these cases, which is fine (although it could be a warn_once), but patch 6/6 is definitely buggy in that we leave the skb in a half edited state when leaving the helper. Daniel, want me to fix this up from bpf side and route 5/6 and actual fix via bpf tree? Otherwise please respin with fixed 6/6. Thanks, Daniel
