[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180417.134727.1681639113353628332.davem@davemloft.net>
Date: Tue, 17 Apr 2018 13:47:27 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: bjorn@...k.no
Cc: netdev@...r.kernel.org, jasowang@...hat.com
Subject: Re: [PATCH net,stable] tun: fix vlan packet truncation
From: Bjørn Mork <bjorn@...k.no>
Date: Tue, 17 Apr 2018 00:00:38 +0200
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 28583aa0c17d..01cf8e3d8edc 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1103,13 +1103,6 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>
> len = run_ebpf_filter(tun, skb, len);
>
> - /* Trim extra bytes since we may insert vlan proto & TCI
> - * in tun_put_user().
> - */
> - len -= skb_vlan_tag_present(skb) ? sizeof(struct veth) : 0;
> - if (len <= 0 || pskb_trim(skb, len))
> - goto drop;
> -
> if (unlikely(skb_orphan_frags_rx(skb, GFP_ATOMIC)))
The VLAN business might be bogus, and needs to be removed.
However, the pskb_trim() has to stay in some form. I think this is what
Jason is trying to say.
The semantics of running a BPF program is that the program returns the
desired packet length. We must truncate the packet to the length
returned by the BPF program, therefore.
Powered by blists - more mailing lists