netdev - iproute2: dealing with tunnel type mismatchs how?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20230407125406.10ac2ec4@hermes.local>
Date:   Fri, 7 Apr 2023 12:54:06 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: iproute2: dealing with tunnel type mismatchs how?

Luca notified us of a bug in iproute2 tunnel change that does not have an easy
way to resolve. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032642

The trigger is doing a ip tunnel change request on the wrong type of tunnel.
In this case it is doing an IPv4 type change on an gre6 tunnel. Doing this
is not a valid thing to do, but the kernel and ip tunnel command do not
handle it well.

The root cause is that socket private ioctl's are a bad design from the start!
The same ioctl can return different data depending on the interface used.
The change request requires that ip tunnel do an ioctl
to get current values, and the returned data depends on the type of tunnel (gre vs gre6).
Netlink related API's don't have this type of issue.

None of the options is great:
1. Leave it alone, this has been this way for 15 years.
1a. Make the call to fetch tunnel parameters with a bigger buffer so
    that failure is not a stack smash, just garbage in.

2. Change kernel ioctl to not allow IPv4 socket to be used when doing IPv6 tunnel
   operations. Not easy since the socket context is not passed down through the
   tunnel ioctl calls.

3. Add logic to ip tunnel to do netlink calls to find the type of device being
   changed, and catch mismatches there. There is not a simple direct way to get
   the type, although it probably could be inferred from the ip link type.

4. The whole 'ip tunnel' set of commands is actually superfluous at this point.
   Same things can be done via 'ip link' and none of the problems happen.
   Therefore, start process of deprecating and removing 'ip tunnel'??

5. Remove the change option from 'ip tunnel'.  And force the user to make
   a new tunnel if they want to change endpoints etc.

Ideas and comments appreciated.