netdev - Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

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: <20070203150631.GC32659@hmsreliant.homelinux.net>
Date:	Sat, 3 Feb 2007 10:06:31 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Vlad Yasevich <vladislav.yasevich@...com>
Cc:	David Miller <davem@...emloft.net>, yoshfuji@...ux-ipv6.org,
	sri@...ibm.com, kuznet@....inr.ac.ru, pekkas@...core.fi,
	jmorris@...ei.org, kaber@...eworks.de, netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

On Fri, Feb 02, 2007 at 05:22:31PM -0500, Vlad Yasevich wrote:
> Neil Horman wrote:
> > On Fri, Feb 02, 2007 at 11:46:08AM -0800, David Miller wrote:
> >> From: Neil Horman <nhorman@...driver.com>
> >> Date: Fri, 2 Feb 2007 14:06:34 -0500
> >>
> >>> Ok, I'm still testing it, but heres a new patch for review.
> >>> Significant changes include the addition of a
> >>> CONFIG_IPV6_OPTIMISTIC_DAD option that is dependent on the inclusion
> >>> of both IPPV6 and EXPERIMENTAL options, as well as a new method for
> >>> redirecting packets from optimistic sources to incomplete neighbors
> >>> by instead looking up a default router in ip6_dst_lookup_tail, as I
> >>> described in my previous note.
> >> This looks largely fine to me, but I wonder about one bit:
> >>
> >> +
> >> +	/*
> >> +	 * Optimistic nodes need to join the anycast address
> >> +	 * right away
> >> +	 */
> >> +	if (ifp->flags & IFA_F_OPTIMISTIC)
> >> +		addrconf_join_anycast(ifp);
> >> +
> >>
> >> If something can clear that bit during the DAD, we won't
> >> call addrconf_leave_anycast() later.  Can that happen?
> > The only way the flag should get cleared once we've started DAD is when it
> > completes or fails.  In the failure case, we destroy the ifaddr structure, which
> > I think should force a leave_anycast, while the completed condition calls
> > addrconf_leave_anycast as part of the completion process before it clears the
> > flags, so I think we should be ok.  If anyone sees anything to the contrary,
> > please let me know and I'll be sure to  plug the hole.
> 
> I think there is a hole:
> 
> Looking for addrconf_leave_anycast() shows:
> dev_forward_change():	475 addrconf_leave_anycast(ifa);
> __ipv6_ifa_notify():	3613 addrconf_leave_anycast(ifp);
> 
> Problem:  __ipv6_ifa_notify only performs the 'leave' if forwarding is enabled.
> 	  However, OPTIMISTIC, is set when forwarding is _disabled_.
> 
> 
> -vlad
I think you may be right.  I'll fix that up monday AM.  Thanks!
Neil

-
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