On 03/01/2018 01:17 AM, Daniel Axtens wrote:
[...]
>>> 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
Hi Daniel,
>> 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
On 02/28/2018 04:56 PM, David Miller wrote:
> From: Daniel Axtens
> 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
From: Daniel Axtens
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()
>
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