netdev - Re: [PATCH net-next] [v2] bonding: remove entries for master_ip and vlan

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] [day] [month] [year] [list]

Message-ID: <20120322202222.GA15291@gospo.rdu.redhat.com>
Date:	Thu, 22 Mar 2012 16:22:22 -0400
From:	Andy Gospodarek <andy@...yhouse.net>
To:	David Miller <davem@...emloft.net>
Cc:	andy@...yhouse.net, netdev@...r.kernel.org, ralf.zeidler@....com
Subject: Re: [PATCH net-next] [v2] bonding: remove entries for master_ip
	and vlan_ip and query devices instead

On Wed, Mar 21, 2012 at 10:34:11PM -0400, David Miller wrote:
> From: Andy Gospodarek <andy@...yhouse.net>
> Date: Wed, 21 Mar 2012 17:36:42 -0400
> 
> > As the Subject indicates this patch drops the master_ip and vlan_ip
> > elements from the 'bonding' and 'vlan_entry' structs, respectively.
> > This can be done because a device's address-list is now traversed to
> > determine the optimal source IP address for ARP requests and for checks
> > to see if the bonding device has a particular IP address.  This code
> > could have all be contained inside the bonding driver, but it made more
> > sense to me to EXPORT and call inet_confirm_addr since it did exactly
> > what was needed.
> 
> I like this patch a lot but you have one little bug that needs to be
> fixed:
> 
> > +	rcu_read_lock();
> > +	in_dev = __in_dev_get_rcu(dev);
> > +	rcu_read_unlock();
> > +
> > +	if (in_dev)
> > +		addr = inet_confirm_addr(in_dev, dst, local, RT_SCOPE_HOST);
> 
> If you're going to do an RCU ref-less lookup of in_dev and then use
> it, you have to include the "use" inside of the RCU protected section
> as well.
> 
> Otherwise as soon as you rcu_read_unlock() the in_dev could be freed
> up on you.
> 
> The only exception would be if you know that all callers of
> bond_confirm_addr() ran in an RCU protected section, but I do not
> think that is universally the case here.
> 
> If you think it might be the case that we are RCU protected in all of
> these code paths already, you can remove the RCU locking altogether
> from bond_confirm_addr() and run with lockdep enabled while exercising
> all of the relevant code paths.


Thanks for catching that, Dave.  I'm pretty sure there is at least one
path where rcu_read_lock has not already been called so the protection
is needed.  I know that rcu_read_lock/unlock is called in
inet_confirm_addr, but since rcu locks can be nested, so I'll go ahead
and make that change.

There are 2 more places in the bonding driver where this is also done
incorrectly in some vlan code, so I'll fix those with a subsequent patch.

--
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