Commit 5ce54af1 authored Jun 08, 2014 by Dmitry Popov Committed by David S. Miller Jun 11, 2014

ip_tunnel: fix i_key matching in ip_tunnel_find



Some tunnels (though only vti as for now) can use i_key just for internal use:
for example vti uses it for fwmark'ing incoming packets. So raw i_key value
shouldn't be treated as a distinguisher for them. ip_tunnel_key_match exists for
cases when we want to compare two ip_tunnel_parms' i_keys.

Example bug:
ip link add type vti ikey 1 local 1.0.0.1 remote 2.0.0.2
ip link add type vti ikey 2 local 1.0.0.1 remote 2.0.0.2
spawned two tunnels, although it doesn't make sense.

Signed-off-by: Dmitry Popov <ixaphire@qrator.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

parent 7c8e6b9c

net/ipv4/ip_tunnel.c

+3 −2

Original line number	Diff line number	Diff line
		@@ -268,6 +268,7 @@ static struct ip_tunnel ip_tunnel_find(struct ip_tunnel_net itn,
		__be32 remote = parms->iph.daddr;
		__be32 local = parms->iph.saddr;
		__be32 key = parms->i_key;
		__be16 flags = parms->i_flags;
		int link = parms->link;
		struct ip_tunnel *t = NULL;
		struct hlist_head *head = ip_bucket(itn, parms);
		@@ -275,9 +276,9 @@ static struct ip_tunnel ip_tunnel_find(struct ip_tunnel_net itn,
		hlist_for_each_entry_rcu(t, head, hash_node) {
		if (local == t->parms.iph.saddr &&
		remote == t->parms.iph.daddr &&
		key == t->parms.i_key &&
		link == t->parms.link &&
		type == t->dev->type)
		type == t->dev->type &&
		ip_tunnel_key_match(&t->parms, flags, key))
		break;
		}
		return t;