netdev - Re: [BUG] net: gre: IPv6 link-local multicast is silently dropped (Regression)

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]

Message-ID: <aGJ7EvpKRWVzPm4Y@debian>
Date: Mon, 30 Jun 2025 13:54:58 +0200
From: Guillaume Nault <gnault@...hat.com>
To: Ido Schimmel <idosch@...sch.org>
Cc: Aiden Yang <ling@...dove.com>, netdev@...r.kernel.org, kuba@...nel.org,
	pabeni@...hat.com, davem@...emloft.net,
	MoeDove NOC <noc@...dove.com>
Subject: Re: [BUG] net: gre: IPv6 link-local multicast is silently dropped
 (Regression)

On Sun, Jun 29, 2025 at 05:49:36PM +0300, Ido Schimmel wrote:
> + Guillaume
> 
> Report is here: https://lore.kernel.org/netdev/CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com/
> 
> On Sun, Jun 29, 2025 at 02:40:27PM +0800, Aiden Yang wrote:
> > This report details a regression in the Linux kernel that prevents
> > IPv6 link-local all-nodes multicast packets (ff02::1) from being
> > transmitted over a GRE tunnel. The issue is confirmed to have been
> > introduced between kernel versions 6.1.0-35-cloud-amd64 (working) and
> > 6.1.0-37-cloud-amd64 (failing) on Debian 12 (Bookworm).
> 
> Apparently 6.1.0-35-cloud-amd64 is v6.1.137 and 6.1.0-37-cloud-amd64 is
> v6.1.140. Probably started with:
> 
> a51dc9669ff8 gre: Fix again IPv6 link-local address generation.
> 
> In v6.1.139.
> 
> It skips creating an IPv6 multicast route for some ipgre devices. Can
> you try the following diff?
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index ba2ec7c870cc..d0a202d0d93e 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3537,12 +3537,10 @@ static void addrconf_gre_config(struct net_device *dev)
>  	 * case). Such devices fall back to add_v4_addrs() instead.
>  	 */
>  	if (!(dev->type == ARPHRD_IPGRE && *(__be32 *)dev->dev_addr == 0 &&
> -	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {
> +	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64))
>  		addrconf_addr_gen(idev, true);
> -		return;
> -	}
> -
> -	add_v4_addrs(idev);
> +	else
> +		add_v4_addrs(idev);
>  
>  	if (dev->flags & IFF_POINTOPOINT)
>  		addrconf_add_mroute(dev);

I believe that should fix the problem indeed. But, to me, the root
cause is that addrconf_gre_config() doesn't call addrconf_add_dev().

Ido, What do you think of something like the following (untested,
hand-written) diff:

 #if IS_ENABLED(CONFIG_NET_IPGRE)
 static void addrconf_gre_config(struct net_device *dev)
 {
 	struct inet6_dev *idev;
 
 	ASSERT_RTNL();
 
-	idev = ipv6_find_idev(dev);
-	if (IS_ERR(idev)) {
-		pr_debug("%s: add_dev failed\n", __func__);
-		return;
-	}
+	idev = addrconf_add_dev(dev);
+	if (IS_ERR(idev))
+		return;
 
 	/* Generate the IPv6 link-local address using addrconf_addr_gen(),
 	 * unless we have an IPv4 GRE device not bound to an IP address and
 	 * which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this
 	 * case). Such devices fall back to add_v4_addrs() instead.
 	 */
 	if (!(*(__be32 *)dev->dev_addr == 0 &&
 	      idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {
 		addrconf_addr_gen(idev, true);
 		return;
 	}
 
 	add_v4_addrs(idev);
-
-	if (dev->flags & IFF_POINTOPOINT)
-		addrconf_add_mroute(dev);
 }
 #endif

This way, we would create the multicast route and also respect
disable_ipv6. That would bring GRE yet a bit closer to normal IPv6
lladdr generation code.

Note: this diff is based on net-next, but, without all the extra
context lines, a real patch would probably apply to both net and
next-next and could be backported to -stable.

> Guillaume, AFAICT, after commit d3623dd5bd4e ("ipv6: Simplify link-local
> address generation for IPv6 GRE.") in net-next an IPv6 multicast route
> will be created for every ip6gre device, regardless of IFF_POINTOPOINT.
> It should restore the behavior before commit e5dd729460ca ("ip/ip6_gre:
> use the same logic as SIT interfaces when computing v6LL address"). We
> can extend gre_ipv6_lladdr.sh to test this once the fix is in net-next.

Yes, I fully agree.

Long term, I'd really like to remove these special GRE and SIT cases
(SIT certainly has the same problems we're currently fixing on GRE).