netdev - Re: [PATCH] net: bridge: suppress broadcast when multicast flood is disabled

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:   Mon, 24 Apr 2017 22:52:55 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Mike Manning <mmanning@...cade.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: suppress broadcast when multicast flood is
 disabled

On 24/04/17 17:09, Mike Manning wrote:
> Flood suppression for packets that are not unicast needs to be handled
> consistently by also not flooding broadcast packets. As broadcast is a
> special case of multicast, the same kernel parameter should be used to
> suppress flooding for both of these packet types.
> 
> Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag")
> Cc: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Signed-off-by: Mike Manning <mmanning@...cade.com>
> ---
>  net/bridge/br_forward.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 

I do not agree that this is a bug fix, the behaviour was intentional and is close to how HW
handles this flag. It has been like that for a few releases and changing it may impact setups
that use the flag since up until now they've seen the broadcast but not multicast packets and
suddenly their broadcast will stop.

I think it would be better to introduce a third flag for bcast in net-next and use that to
filter it since that would give us the ability to program HW that can distinguish these
and have both options available, moreover it will not break any user setups relying on
the current flag behaviour and we have such setups.

Thanks,
 Nik