forked from Minki/linux
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>
This commit is contained in:
parent
7c8e6b9c28
commit
5ce54af1fc
@ -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;
|
||||
|
Loading…
Reference in New Issue
Block a user