netdev - Re: [PATCH net] ip_tunnel: Don't allow to add the same tunnel multiple times.

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, 23 Sep 2014 13:30:51 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>
Subject: Re: [PATCH net] ip_tunnel: Don't allow to add the same tunnel
 multiple times.

On Mon, Sep 22, 2014 at 04:45:56PM -0400, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@...unet.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@...unet.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html