From owner-freebsd-net@FreeBSD.ORG Tue Feb 7 10:16:18 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19C4616A420 for ; Tue, 7 Feb 2006 10:16:18 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id B763643D49 for ; Tue, 7 Feb 2006 10:16:17 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:0:8002:c0fe:1358:5484:d6fe]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D02391521A; Tue, 7 Feb 2006 19:16:16 +0900 (JST) Date: Tue, 07 Feb 2006 19:16:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Kris Kennaway In-Reply-To: <20060207054502.GA18560@xor.obsecurity.org> References: <20060116004438.GA27901@xor.obsecurity.org> <20060207054502.GA18560@xor.obsecurity.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@FreeBSD.org Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2006 10:16:18 -0000 >>>>> On Tue, 7 Feb 2006 00:45:02 -0500, >>>>> Kris Kennaway 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@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;