netdev - Re: Issue with GRE tunnel, created with "local any" on kernel 3.14

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: <20140718223204.9422aa8df81f7ac5187588bb@qrator.net>
Date:	Fri, 18 Jul 2014 22:32:04 +0400
From:	Dmitry Popov <ixaphire@...tor.net>
To:	Sergey Popov <pinkbyte@...too.org>
Cc:	Tom Herbert <therbert@...gle.com>, netdev@...r.kernel.org
Subject: Re: Issue with GRE tunnel, created with "local any" on kernel 3.14

On Fri, 18 Jul 2014 17:01:23 +0400
Sergey Popov <pinkbyte@...too.org> wrote:

> Hi. I have updated kernel on one of my servers to 3.14 and hit strange
> issue:

> serv1(172.30.0.100) <-> serv2(172.30.0.251)

> Gre tunnel(serv1):
> ip tunnel add tun_test mode gre remote 172.30.0.251 local any ttl 225
> ifconfig tun_test 192.168.0.1/30
> 
> Gre tunnel(serv2):
> ip tunnel add tun_test mode gre remote 172.30.0.100 local any ttl 225
> ifconfig tun_test 192.168.0.2/30

> 16:49:39.340971 IP 0.0.0.0 > 172.30.0.100: GREv0, length 88: IP
> 192.168.0.2 > 192.168.0.1: ICMP echo request, id 5259, seq 7, length 64

Hi!

It seems we have this issue since 7d442fab0 (ipv4: Cache dst in tunnels).
It is in ip_tunnel_xmit: fl4 is initialized with saddr = 0 in
init_tunnel_flow(&fl4, protocol, dst, ...), net/ipv4/ip_tunnel.c:610,
and isn't changed until iptunnel_xmit(skb->sk, ...), line 677, because 
connected = true and rt is almost always cached.

I have no patch to fix this issue, but as a workaround, you can use 
ip tunnel change tun_test tos inherit.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html