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]

Date:	Fri, 02 Feb 2007 17:22:31 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Neil Horman <nhorman@...driver.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

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