From owner-freebsd-net@FreeBSD.ORG Mon May 26 09:19:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B07B13C5 for ; Mon, 26 May 2014 09:19:36 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 756102AEB for ; Mon, 26 May 2014 09:19:35 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id BAA0D2700B7B for ; Mon, 26 May 2014 11:11:31 +0200 (CEST) Received: from stever.netasq.com (unknown [10.2.0.1]) by work.netasq.com (Postfix) with ESMTPA id 5DA262700B77 for ; Mon, 26 May 2014 11:11:31 +0200 (CEST) Message-ID: <53830546.1080309@netasq.com> Date: Mon, 26 May 2014 11:11:34 +0200 From: Steve Read User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Problem: no locking around IPv6 prefix structures in prelist_remove Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 09:19:36 -0000 I have recently encountered an interesting double-free crash in prelist_remove() (management of IPv6 prefixes used by interface addresses) using a modified version of 9.2. We've seen this once. It appears that two userland threads tried simultaneously to remove the last interface address that referenced a particular prefix, and both, therefore, tried to remove it from the global list of prefixes. (Feel free to correct my interpretation of the purpose of prelist_remove and how it is invoked.) One of them succeeded, and the other was left holding a chunk of free()ed memory, and crashed when trying to delete it. I looked at the code surrounding this function, and I can find no sign of locking around the prefix list or, indeed, anywhere in the call-stack (sys_ioctl=>kern_ioctl=>soo_ioctl==>ifi_ioctl=>in6_control=>prelist_remove). I looked in HEAD, and this part of the code appears to be more or less the same, in particular the question of locking. Should I submit a PR (no, we can't retry with a generic kernel)? -- Steve Read