From: Nicolas Dichtel
Date: Wed, 24 Jan 2018 16:37:56 +0100
> I would prefer a patch that test if the handler is available. It
> would prevent to have this bug again in the future. But I don't have
> a strong opinion about this.
Yes that's probably better, making all calls to these dst_ops that
Le 24/01/2018 à 10:49, Roman Kapl a écrit :
> On 01/24/2018 10:16 AM, Xin Long wrote:
>> On Wed, Jan 24, 2018 at 6:42 AM, Roman Kapl wrote:
>>> Tunnel devices often use skb_dst(skb)->ops, but ops are not implemented
>>> for metadata tunnel destinations. Use skb_valid_dst to check if skb_dst
>>> is
On 01/24/2018 10:16 AM, Xin Long wrote:
On Wed, Jan 24, 2018 at 6:42 AM, Roman Kapl wrote:
Tunnel devices often use skb_dst(skb)->ops, but ops are not implemented
for metadata tunnel destinations. Use skb_valid_dst to check if skb_dst
is a real (non-metadata) destination.
Such packets can easi
On Wed, Jan 24, 2018 at 6:42 AM, Roman Kapl wrote:
> Tunnel devices often use skb_dst(skb)->ops, but ops are not implemented
> for metadata tunnel destinations. Use skb_valid_dst to check if skb_dst
> is a real (non-metadata) destination.
>
> Such packets can easily be crafted using tc tunnel_key
Tunnel devices often use skb_dst(skb)->ops, but ops are not implemented
for metadata tunnel destinations. Use skb_valid_dst to check if skb_dst
is a real (non-metadata) destination.
Such packets can easily be crafted using tc tunnel_key actions or BPF
and will crash the tunnels, as observed at lea
