netdev - RE: [PATCH net-next 2/4] bonding: use common mac addr checks

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: <9b51c882f54244e5972da43d7955c959@usma1ex-dag1mb2.msg.corp.akamai.com>
Date:   Fri, 11 May 2018 21:25:07 +0000
From:   "Banerjee, Debabrata" <dbanerje@...mai.com>
To:     'Jay Vosburgh' <jay.vosburgh@...onical.com>
CC:     "David S . Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Veaceslav Falico <vfalico@...il.com>,
        "Andy Gospodarek" <andy@...yhouse.net>
Subject: RE: [PATCH net-next 2/4] bonding: use common mac addr checks

> From: Jay Vosburgh [mailto:jay.vosburgh@...onical.com]
> Debabrata Banerjee <dbanerje@...mai.com> wrote:

> >-				if
> (!ether_addr_equal_64bits(rx_hash_table[index].mac_dst,
> >-							     mac_bcast) &&
> >-
> !is_zero_ether_addr(rx_hash_table[index].mac_dst)) {
> >+				if
> (is_valid_ether_addr(rx_hash_table[index].mac_dst)) {
> 
> 	This change and the similar ones below will now fail non-broadcast
> multicast Ethernet addresses, where the prior code would not.  Is this an
> intentional change?

Yes I don't see how it makes sense to use multicast addresses at all, but I may be missing something. It's also illegal according to rfc1812 3.3.2, but obviously this balancing mode is trying to be very clever. We probably shouldn't violate the rfc anyway.