Re: [PATCH net] ip6_gre: fix changelink conflict checks for L2 tunnels

[Ido Schimmel <idosch@nvidia.com>]

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: stable@vger.kernel.org
> Signed-off-by: Xia Yan <yanxia@cmss.chinamobile.com>

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/
[2] https://lkml.org/lkml/2018/6/24/113
[3] https://lwn.net/Articles/1074171/
[4] https://netdev.bots.linux.dev/net-next.html