netdev - Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

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: <aOEu6uQ4pP4PJH-y@sellars>
Date: Sat, 4 Oct 2025 16:27:54 +0200
From: Linus Lüssing <linus.luessing@...3.blue>
To: Ido Schimmel <idosch@...dia.com>
Cc: "Huang, Joseph" <joseph.huang.at.garmin@...il.com>,
	Joseph Huang <Joseph.Huang@...min.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	David Ahern <dsahern@...nel.org>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Kuniyuki Iwashima <kuniyu@...gle.com>,
	Ahmed Zaki <ahmed.zaki@...el.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	linux-kernel@...r.kernel.org, bridge@...ts.linux.dev
Subject: Re: [PATCH net] net: bridge: Trigger host query on v6 addr valid

On Wed, Sep 17, 2025 at 02:30:51PM +0300, Ido Schimmel wrote:
> But before making changes, I want to better understand the problem you
> are seeing. Is it specific to the offloaded data path? I believe the
> problem was fixed in the software data path by this commit:

Two issues I noticed recently, even without any hardware switch
offloading, on plain soft bridges:

1) (Probably not the issue here? But just to avoid that this
causes additional confusion:) we don't seem to properly converge to
the lowest MAC address, which is a bug, a violation of the RFCs.

If we received an IGMP/MLD query from a foreign host with an
address like fe80::2 and selected it and then enable our own
multicast querier with a lower address like fe80::1 on our bridge
interface for example then we won't send our queries, won't reelect
ourself. If I recall correctly. (Not too critical though, as at least we
have a querier on the link. But I find the election code a bit
confusing and I wouldn't dare to touch it without adding some tests.)

2) Without Ido's suggested workaround when the bridge multicast snooping
+ querier is enabled before the IPv6 DAD has taken place then our
first IGMP/MLD query will fizzle, not be transmitted.

However (at least for a non-hardware-offloaded) bridge as far as I
recall this shouldn't create any multicast packet loss and should
operate as "normal" with flooding multicast data packets first,
with multicast snooping activating on multicast data
after another IGMP/MLD querier interval has elapsed (default:
125 sec.)?

Which indeed could be optimized and is confusing, this delay could
be avoided. Is that that the issue you mean, Joseph?
(I'd consider it more an optimization, so for net-next, not
net though.)

> In current implementation, :: always wins the election

That would be news to me.

RFC2710, section 5:

   To be valid, the Query message MUST come from a link-
   local IPv6 Source Address

RFC3810, section 5.1.14, is even more explicit:

   5.1.14.  Source Addresses for Queries

   All MLDv2 Queries MUST be sent with a valid IPv6 link-local source
   address.  If a node (router or host) receives a Query message with
   the IPv6 Source Address set to the unspecified address (::), or any
   other address that is not a valid IPv6 link-local address, it MUST
   silently discard the message and SHOULD log a warning.

So :: can't be used as a source address for an MLD query.
And since 2014 with "bridge: multicast: add sanity check for query source addresses"
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6565b9eeef194afbb3beec80d6dd2447f4091f8c)
we should be adhering to that requirement? Let me know if I'm missing
something.

For IPv4 and 0.0.0.0 this is a different story though... I'm not
aware of a requirement in RFCs to avoid 0.0.0.0 in IGMP
queries. And "intuitively" one would prefer 0.0.0.0 to be the
least prefered querier address. But when taking the IGMP RFCs
literally then 0.0.0.0 would be the lowest one and always win... And RFC4541
unfortunately does not clarify the use of 0.0.0.0 for IGMP queries.
Not quite sure what the common practice among other layer 2 multicast
snooping implemetations across other vendos is.

> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0888d5f3c0f183ea6177355752ada433d370ac89
> 
> And Linus is working [1][2] on reflecting it to device drivers so that
> the hardware data path will act like the software data path and flood
> unregistered multicast traffic to all the ports as long as no querier
> was detected.

Right, for hardware offloading bridges/switches I'm on it, next
revision shouldn't take much longer...

Regards, Linus