From owner-freebsd-bugs@FreeBSD.ORG Sat Feb 11 17:00:24 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2499316A420 for ; Sat, 11 Feb 2006 17:00:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8F9F43D46 for ; Sat, 11 Feb 2006 17:00:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1BH0NaT095386 for ; Sat, 11 Feb 2006 17:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1BH0NBs095385; Sat, 11 Feb 2006 17:00:23 GMT (envelope-from gnats) Date: Sat, 11 Feb 2006 17:00:23 GMT Message-Id: <200602111700.k1BH0NBs095385@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: David Malone Cc: Subject: Re: kern/93170 : Changing system date causes panic in nd6_timer X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Malone List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2006 17:00:24 -0000 The following reply was made to PR kern/93170; it has been noted by GNATS. From: David Malone To: bug-followup@FreeBSD.org, kris@FreeBSD.org Cc: rwatson@FreeBSD.org, iedowse@maths.tcd.ie, dwmalone@maths.tcd.ie Subject: Re: kern/93170 : Changing system date causes panic in nd6_timer Date: Sat, 11 Feb 2006 16:59:38 +0000 I'm fairly sure I know what's going on here, as I've seen a few more of these panics. There seems to be a bundle of IPv6 neighbour discovery code that uses splnet() and hasn't had any locking added to it yet. One of these bits of code is walking some global lists and is obviously getting into trouble. I believe this same code is also causing dirhash panics people have reported 'cos some of the memory it is using is getting reused by dirhash. I sent the message below to Robert a while ago - since I haven't heard back from him, I'm going to have a go at adding some locking. David. Subject: IPv6 address list locking. Date: Fri, 20 Jan 2006 17:48:57 +0000 From: David Malone Message-ID: <200601201748.aa69772@salmon.maths.tcd.ie> Hi Robert, I've been trying to trace some use-after-free problems that have paniced the kernel in dirhash. A few weeks ago I got a panic that indicated that the ifnet malloc pool might be the problem. Using memguard on my desktop in Dublin paniced today and, judging by the reports of the guy who reset it for me, it paniced at nd6_timer+0xe8. This looks like a bit of nd6_timer code that accesses a global list of IPv6 addresses stored in a variable called in6_ifaddr. Rather annoyingly this variable has the same name as a structure, so it is difficult to grep for. However, I don't see any locking of accesses to this variable. Do you have a scheme for locking globals like this in the IPv6 stack? Does it look like nd6_timeout is violaing this locking? David. in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) { in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) { in6.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) { in6_src.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) { nd6.c: for (ia6 = in6_ifaddr; ia6; ia6 = nia6) { nd6.c: for (ia = in6_ifaddr; ia; ia = ia_next) { nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) { nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) { nd6_rtr.c: for (ifa = in6_ifaddr; ifa; ifa = ifa->ia_next) { nd6_rtr.c: for (ia = in6_ifaddr; ia; ia = ia->ia_next) {