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]
Date:   Tue, 5 Sep 2017 20:14:30 -0700
From:   Alexei Starovoitov <ast@...com>
To:     Haishuang Yan <yanhaishuang@...s.chinamobile.com>,
        "David S. Miller" <davem@...emloft.net>
CC:     <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md
 mode

On 9/4/17 1:36 AM, Haishuang Yan wrote:
> In collect_md mode, if the tun dev is down, it still can call
> __ip6_tnl_rcv to receive on packets, and the rx statistics increase
> improperly.
>
> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
> Cc: Alexei Starovoitov <ast@...com>
> Signed-off-by: Haishuang Yan <yanhaishuang@...s.chinamobile.com>
>
> ---
> Change since v3:
>   * Increment rx_dropped if tunnel device is not up, suggested by
>   Pravin B Shelar
>   * Fix wrong recipient address
> ---
>  net/ipv6/ip6_tunnel.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 10a693a..e91d3b6 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -171,8 +171,11 @@ static struct net_device_stats *ip6_get_stats(struct net_device *dev)
>  	}
>
>  	t = rcu_dereference(ip6n->collect_md_tun);
> -	if (t)
> -		return t;
> +	if (t) {
> +		if (t->dev->flags & IFF_UP)
> +			return t;
> +		t->dev->stats.rx_dropped++;
> +	}

Why increment the stats only for this drop case?
There are plenty of other conditions where packet
will be dropped in ip6 tunnel. I think it's important
to present consistent behavior to the users,
so I'd increment drop stats either for all drop cases
or for none. And today it's none.
The ! IFF_UP case should probably be return NULL too.

Powered by blists - more mailing lists