On Wed, Oct 28, 2026 at 07:57:10PM +0800, Xia Yan wrote:
ip6gre_changelink_common() calls ip6gre_tunnel_locate(), which only
looks for ARPHRD_IP6GRE devices. The same changelink helper also handles
ip6gretap and ip6erspan devices.
This lets an L2 tunnel change its parameters to match another L2 tunnel,
since the duplicate check looks for an L3 device instead. Incoming
packets can then be delivered to the wrong interface. An L3 tunnel with
matching parameters can also make a valid L2 update fail with EEXIST.
Use ip6gre_tunnel_find() with dev->type, as the newlink paths do.
Found while comparing the duplicate checks in newlink and changelink.
Confirmed with ip link commands. For example, with an IPv6 underlay
named under already configured:
ip link add tap1 type ip6gretap local fd26:106::1 \
remote fd26:106::2 key 100 dev under
ip link add tap2 type ip6gretap local fd26:106::1 \
remote fd26:106::2 key 200 dev under
ip link set tap1 up
ip link set tap2 up
ip link set tap2 type ip6gretap key 100
Before the fix, the last command succeeds and received frames move from
tap1 to tap2. After the fix, it fails with EEXIST and tap2 is unchanged.
Tested with standalone namespace tests in UML, with three runs each for
ip6gretap and ip6erspan, and with L3 GRE IPv4/IPv6 traffic and normal
tunnel updates. Full x86_64 W=1 builds with adjusted configurations
completed before and after with no new diagnostics.
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Cc: <redacted>
Signed-off-by: Xia Yan <redacted>
Diff looks OK, but this is not a regression [1][2][3]. Broken since 2012
and nobody complained. Please remove the Fixes and stable tags and
target net-next when it re-opens [4].
[1] https://lore.kernel.org/netdev/CAHk-=wiSnTE9vBZ=5_v+3EEkdazCCbBM5YABRzRHUAeRdyd4Xw@mail.gmail.com/ (local)
[2] https://lkml.org/lkml/2018/6/24/113
[3] https://lwn.net/Articles/1074171/
[4] https://netdev.bots.linux.dev/net-next.html