netdev - Re: [PATCHv4 net 5/8] tunnel: do not confirm neighbor when do pmtu update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191221184322.GD7352@linux.home>
Date:   Sat, 21 Dec 2019 19:43:22 +0100
From:   Guillaume Nault <gnault@...hat.com>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     netdev@...r.kernel.org, Julian Anastasov <ja@....bg>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        David Ahern <dsahern@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        David Miller <davem@...emloft.net>,
        Pablo Neira <pablo@...filter.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexey Kodanev <alexey.kodanev@...cle.com>
Subject: Re: [PATCHv4 net 5/8] tunnel: do not confirm neighbor when do pmtu
 update

On Fri, Dec 20, 2019 at 11:25:22AM +0800, Hangbin Liu wrote:
> When do tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end,
> we should not call dst_confirm_neigh() as there is no two-way communication.
> 
> v4: Update commit description
> v3: Do not remove dst_confirm_neigh, but add a new bool parameter in
>     dst_ops.update_pmtu to control whether we should do neighbor confirm.
>     Also split the big patch to small ones for each area.
> v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu.
> 
> Fixes: 0dec879f636f ("net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP")
> Reviewed-by: Guillaume Nault <gnault@...hat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> ---
>  net/ipv4/ip_tunnel.c  | 2 +-
>  net/ipv6/ip6_tunnel.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 38c02bb62e2c..0fe2a5d3e258 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -505,7 +505,7 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
>  		mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>  
>  	if (skb_valid_dst(skb))
> -		skb_dst_update_pmtu(skb, mtu);
> +		skb_dst_update_pmtu_no_confirm(skb, mtu);
>  
>  	if (skb->protocol == htons(ETH_P_IP)) {
>  		if (!skb_is_gso(skb) &&
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 754a484d35df..2f376dbc37d5 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -640,7 +640,7 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>  		if (rel_info > dst_mtu(skb_dst(skb2)))
>  			goto out;
>  
> -		skb_dst_update_pmtu(skb2, rel_info);
> +		skb_dst_update_pmtu_no_confirm(skb2, rel_info);
>  	}
>  
>  	icmp_send(skb2, rel_type, rel_code, htonl(rel_info));
> @@ -1132,7 +1132,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
>  	mtu = max(mtu, skb->protocol == htons(ETH_P_IPV6) ?
>  		       IPV6_MIN_MTU : IPV4_MIN_MTU);
>  
> -	skb_dst_update_pmtu(skb, mtu);
> +	skb_dst_update_pmtu_no_confirm(skb, mtu);
>  	if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) {
>  		*pmtu = mtu;
>  		err = -EMSGSIZE;

Tested-by: Guillaume Nault <gnault@...hat.com>

Note that ip6gretap devices seem to accept frames regardless of their
destination MAC address. That's wrong, but makes this bug invisible
in practice.