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

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

Message-ID: <aYUr3_Y41MbygOfv@sellars>
Date: Fri, 6 Feb 2026 00:46:39 +0100
From: Linus Lüssing <linus.luessing@...3.blue>
To: "Huang, Joseph" <joseph.huang.at.garmin@...il.com>
Cc: Ido Schimmel <idosch@...dia.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 Mon, Oct 06, 2025 at 11:43:02AM -0400, Huang, Joseph wrote:
> Some systems could not afford to flood multicast traffic. Think of some
> resource-constrained low power sensors connected to a network with high
> volume multicast video traffic for example. The multicast traffic could
> easily choke the sensors and is essentially a DDoS attack.

Just to avoid a misunderstanding, I'm not against the idea of this
patch, to make sure that an MLD query is send as soon as an IPv6
link-local address becomes available.

I also agree that high multicast traffic, as it typically has no congestion
control, can easily saturate low bandwidth links. Annoyingly, WLAN
has a linear backoff time for multicast/broadcast packets while
unicast packets haven an exponential backoff (if I recall
correctly).

> 
> > 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.)
> > 
> 
> I'm not sure this should be categorized as an optimization. If we never
> intend to send Startup Queries, that's a different story. But if we intend
> to send it but failed, I think that should be a bug.

For net:
https://docs.kernel.org/process/stable-kernel-rules.html#stable-kernel-rules
-> "It must either fix a real bug that bothers people or just add a device ID."

(But I'm also not 100% sure if this rule is applicable here.)


> 
> > > 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.
> > 
> 
> This is what I meant by ":: always wins":
> 
> In br_multicast_select_querier(),
> 
> 	if (ipv6_addr_cmp(&saddr->src.ip6, &querier->addr.src.ip6) <= 0)
> 		goto update;

Did you take into account that a :: query source should not get
until here because such a query should be dropped as invalid in
br_multicast_ipv6_rcv() -> ipv6_mc_check_mld()?

If you've seen a :: MLD query win in the bridge in the wild though,
I'd be very interested in some debug output, that shouldn't be as
intended / would be a serious bug then, as it would violate the RFC
mentioned above. An MLD query with :: source addres simply would not
work. The Linux IPv6 host stack for instance just drops/ignores it here:
https://elixir.bootlin.com/linux/v6.18.6/source/net/ipv6/mcast.c#L1450
Just as the RFC requires.

(And yes, the informational RFC4541, section 3 is also broken in that
regard, where it says "... should use the null IP source address (::) when
sending said [non-querier general query spoofing switch] querier".
That conflicts with RFC3810, section 5.1.14 or RFC2710, section 5.
You won't get the MLD reports you're asking for with ::. Feel free
to try :-). )

> 1. querier->addr.src.ip6 is (un)initialized(?) to 0 (I couldn't find the
> place where ip6_querier.addr is initialized)

br_multicast_update_querier()
-> memcpy(&querier->addr, saddr, sizeof(*saddr))" ?

Regards, Linus