netdev - Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup

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]

Date:	Tue, 5 Jul 2011 22:35:51 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, mike@...loops.com,
	netdev@...r.kernel.org
Subject: Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP
 setup

On Wed, 6 Jul 2011 13:08:48 +0800
Herbert Xu <herbert@...dor.apana.org.au> wrote:

> On Tue, Jul 05, 2011 at 10:06:36PM -0700, Stephen Hemminger wrote:
> > On Tue, 05 Jul 2011 18:40:44 -0700 (PDT)
> > David Miller <davem@...emloft.net> wrote:
> > 
> > > From: Herbert Xu <herbert@...dor.hengli.com.au>
> > > Date: Wed, 6 Jul 2011 07:58:33 +0800
> > > 
> > > > bridge: Always flood broadcast packets
> > > > 
> > > > As is_multicast_ether_addr returns true on broadcast packets as
> > > > well, we need to explicitly exclude broadcast packets so that
> > > > they're always flooded.  This wasn't an issue before as broadcast
> > > > packets were considered to be an unregistered multicast group,
> > > > which were always flooded.  However, as we now only flood such
> > > > packets to router ports, this is no longer acceptable.
> > > > 
> > > > Reported-by: Michael Guntsche <mike@...loops.com>
> > > > Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
> > > 
> > > Applied.
> > 
> > Obviously needs to go to stable as well.
> 
> I don't think the buggy patch has made it to a release kernel
> yet.
> 
> Thanks,

The bisected commit bd4265fe36 is in 3.0-rc4 but the input code
path still treats multicast and broadcast the same which means
there are some other possible cases where broadcast doesn't get
forwarded.

Wouldn't it make more sense to force input path to always forward
broadcasts. It would also save a lookup of mdb entry.

--- a/net/bridge/br_input.c	2011-07-05 22:28:30.111995701 -0700
+++ b/net/bridge/br_input.c	2011-07-05 22:34:08.259995671 -0700
@@ -77,7 +77,9 @@ int br_handle_frame_finish(struct sk_buf
 
 	dst = NULL;
 
-	if (is_multicast_ether_addr(dest)) {
+	if (is_broadcast_ether_addr(dest))
+		skb2 = skb;
+	else if (is_multicast_ether_addr(dest)) {
 		mdst = br_mdb_get(br, skb);
 		if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
 			if ((mdst && mdst->mglist) ||

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html