| Message ID | 20140922071108.GY6390@secunet.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Steffen Klassert <steffen.klassert@secunet.com> Date: Mon, 22 Sep 2014 09:11:08 +0200 > When we try to add an already existing tunnel, we don't return > an error. Instead we continue and call ip_tunnel_update(). > This means that we can change existing tunnels by adding > the same tunnel multiple times. It is even possible to change > the tunnel endpoints of the fallback device. > > We fix this by returning an error if we try to add an existing > tunnel. > > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> > --- > > I was not able to find a commit that introduced this bug. > Looks like ipip and ip_gre had similar bugs already with > the initial git commit. I'm not so sure about this, perhaps the behavior of being able to change a configuration using an ADD call is intentional? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 22, 2014 at 04:45:56PM -0400, David Miller wrote: > From: Steffen Klassert <steffen.klassert@secunet.com> > Date: Mon, 22 Sep 2014 09:11:08 +0200 > > > When we try to add an already existing tunnel, we don't return > > an error. Instead we continue and call ip_tunnel_update(). > > This means that we can change existing tunnels by adding > > the same tunnel multiple times. It is even possible to change > > the tunnel endpoints of the fallback device. > > > > We fix this by returning an error if we try to add an existing > > tunnel. > > > > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> > > --- > > > > I was not able to find a commit that introduced this bug. > > Looks like ipip and ip_gre had similar bugs already with > > the initial git commit. > > I'm not so sure about this, perhaps the behavior of being able to > change a configuration using an ADD call is intentional? Hm, I don't think so. Initially it was the same like with ipv6. It was possible to add the same tunnel muliple times without getting an error, no config change was made. The possibilty to change the configuration by adding the same tunnel a second time came with the tunnel code unification. I think we should return an error if a tunnel configuration is added a second time. Otherwise we can do something like: ip tunnel add name tunl1 mode ipip local 0.0.0.0 remote 0.0.0.0 ip tunnel add name tunl2 mode ipip local 0.0.0.0 remote 0.0.0.0 ip tunnel add name tunl3 mode ipip local 0.0.0.0 remote 0.0.0.0 None of these tunnels is created because the configuration matches the fallback tunnel, but we don't notify the user about that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Steffen Klassert <steffen.klassert@secunet.com> Date: Tue, 23 Sep 2014 13:30:51 +0200 > On Mon, Sep 22, 2014 at 04:45:56PM -0400, David Miller wrote: >> From: Steffen Klassert <steffen.klassert@secunet.com> >> Date: Mon, 22 Sep 2014 09:11:08 +0200 >> >> > When we try to add an already existing tunnel, we don't return >> > an error. Instead we continue and call ip_tunnel_update(). >> > This means that we can change existing tunnels by adding >> > the same tunnel multiple times. It is even possible to change >> > the tunnel endpoints of the fallback device. >> > >> > We fix this by returning an error if we try to add an existing >> > tunnel. >> > >> > Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> >> > --- >> > >> > I was not able to find a commit that introduced this bug. >> > Looks like ipip and ip_gre had similar bugs already with >> > the initial git commit. >> >> I'm not so sure about this, perhaps the behavior of being able to >> change a configuration using an ADD call is intentional? > > Hm, I don't think so. Initially it was the same like with ipv6. > It was possible to add the same tunnel muliple times without > getting an error, no config change was made. The possibilty > to change the configuration by adding the same tunnel a second > time came with the tunnel code unification. Ok, makes sense. Applied, thanks Steffen. If I had a euro for every regression introduced by that tunnel unification patch set I'd be a rich man indeed :-/ -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index afed1aa..8fb8da9 100644 --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -764,9 +764,14 @@ int ip_tunnel_ioctl(struct net_device *dev, struct ip_tunnel_parm *p, int cmd) t = ip_tunnel_find(itn, p, itn->fb_tunnel_dev->type); - if (!t && (cmd == SIOCADDTUNNEL)) { - t = ip_tunnel_create(net, itn, p); - err = PTR_ERR_OR_ZERO(t); + if (cmd == SIOCADDTUNNEL) { + if (!t) { + t = ip_tunnel_create(net, itn, p); + err = PTR_ERR_OR_ZERO(t); + break; + } + + err = -EEXIST; break; } if (dev != itn->fb_tunnel_dev && cmd == SIOCCHGTUNNEL) {
When we try to add an already existing tunnel, we don't return an error. Instead we continue and call ip_tunnel_update(). This means that we can change existing tunnels by adding the same tunnel multiple times. It is even possible to change the tunnel endpoints of the fallback device. We fix this by returning an error if we try to add an existing tunnel. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> --- I was not able to find a commit that introduced this bug. Looks like ipip and ip_gre had similar bugs already with the initial git commit. net/ipv4/ip_tunnel.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)