linux-kernel - Re: [PATCH net] net/qlcnic: fix mac address restore in bond mode 5/6

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: <20151107.131749.1683961316470551613.davem@davemloft.net>
Date:	Sat, 07 Nov 2015 13:17:49 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	jarod@...hat.com
Cc:	linux-kernel@...r.kernel.org, Dept-GELinuxNICDev@...gic.com,
	netdev@...r.kernel.org, manish.chopra@...gic.com
Subject: Re: [PATCH net] net/qlcnic: fix mac address restore in bond mode
 5/6

From: Jarod Wilson <jarod@...hat.com>
Date: Fri,  6 Nov 2015 09:25:31 -0500

> The bonding driver saves a copy of slaves' original mac address and then
> assigns whatever mac as needed to the slave, depending on mode. In at
> least modes 5 and 6 (balance-tlb, balance-alb), it often ends up being the
> mac address of another slave. On release from the bond, the original mac
> address is supposed to get restored via a dev_set_mac_address() call in
> the bonding driver's __bond_release_one() function, which calls the
> slave's ndo_set_mac_address function, which for qlcnic, is
> qlcnic_set_mac().
> 
> Now, this function tries to be somewhat intelligent and exit early if
> you're trying to set the mac address to the same thing that is already
> set. The problem here is that adapter->mac_addr isn't in sync with
> netdev->dev_addr. The qlcnic driver still has the original mac stored in
> adapter->mac_addr, while the bonding driver has updated netdev->dev_addr,
> so qlcnic thinks we're trying to set the same address it already has.
> 
> I think the way to go here, since the function updates both netdev and
> adapter's stored mac addresses, is to check if either of them doesn't
> match the newly requested mac. Simply checking netdev's value only could
> result in a similar mismatch and non-update, so look at both.
> 
> CC: Dept-GELinuxNICDev@...gic.com
> CC: netdev@...r.kernel.org
> CC: Manish Chopra <manish.chopra@...gic.com>
> Signed-off-by: Jarod Wilson <jarod@...hat.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/