Changing time causes ipv6 panics

[JINMEI Tatuya / 神明達哉]

>>>>> On Tue, 7 Feb 2006 00:45:02 -0500, 
>>>>> Kris Kennaway <kris at obsecurity.org> said:

>> I ran ntpdate on an amd64 system with ipv6 enabled and a skewed clock
>> (ntpdate stepped it back by about an hour), and immediately got a
>> use-after-free panic in ifaddr.  When I rebooted with memguard enabled
>> on this malloc type and retried, I got this panic upon changing the
>> date forward, then back, then forward again (also note the garbage
>> return data from ntpdate):

> Has anyone looked at this?  This is on the TODO list for 6.1, so the
> sooner it can be resolved the better.

Sorry, not really (we've not got a test environment to reproduce it).
But from a quick review of nd6.c, there seems to be one thing that is
obviously wrong.  The possible bug has been there since rev. 1.19
committed in April 2002.  We've been probably just lucky so far...

Could you try the patch attached below?  We'll probably also need to
apply this fix to 4.X and 5.X.

(a note about the patch: the first chunk is actually not related to
the bug, but I could not miss the trivial typo)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp

--- nd6.c.orig	Tue Feb  7 18:58:04 2006
+++ nd6.c	Tue Feb  7 18:59:33 2006
@@ -547,7 +547,7 @@
 	/*
 	 * expire interface addresses.
 	 * in the past the loop was inside prefix expiry processing.
-	 * However, from a stricter speci-confrmance standpoint, we should
+	 * However, from a stricter spec-confrmance standpoint, we should
 	 * rather separate address lifetimes and prefix lifetimes.
 	 */
   addrloop:
@@ -578,8 +578,7 @@
 
 			if (regen)
 				goto addrloop; /* XXX: see below */
-		}
-		if (IFA6_IS_DEPRECATED(ia6)) {
+		} else if (IFA6_IS_DEPRECATED(ia6)) {
 			int oldflags = ia6->ia6_flags;
 
 			ia6->ia6_flags |= IN6_IFF_DEPRECATED;