From owner-svn-src-stable-10@freebsd.org Wed Dec 2 17:26:38 2015 Return-Path: Delivered-To: svn-src-stable-10@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD80CA3FDEA; Wed, 2 Dec 2015 17:26:38 +0000 (UTC) (envelope-from fabient@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 625821A47; Wed, 2 Dec 2015 17:26:38 +0000 (UTC) (envelope-from fabient@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id tB2HQbwB056014; Wed, 2 Dec 2015 17:26:37 GMT (envelope-from fabient@FreeBSD.org) Received: (from fabient@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id tB2HQb5p056013; Wed, 2 Dec 2015 17:26:37 GMT (envelope-from fabient@FreeBSD.org) Message-Id: <201512021726.tB2HQb5p056013@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: fabient set sender to fabient@FreeBSD.org using -f From: Fabien Thomas Date: Wed, 2 Dec 2015 17:26:37 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r291652 - stable/10/sys/netinet X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:26:38 -0000 Author: fabient Date: Wed Dec 2 17:26:37 2015 New Revision: 291652 URL: https://svnweb.freebsd.org/changeset/base/291652 Log: MFC r291301: The r241129 description was wrong that the scenario is possible only for read locks on pcbs. The same race can happen with write lock semantics as well. The race scenario: - Two threads (1 and 2) locate pcb with writer semantics (INPLOOKUP_WLOCKPCB) and do in_pcbref() on it. - 1 and 2 both drop the inp hash lock. - Another thread (3) grabs the inp hash lock. Then it runs in_pcbfree(), which wlocks the pcb. They must happen faster than 1 or 2 come INP_WLOCK()! - 1 and 2 congest in INP_WLOCK(). - 3 does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(), which doesn't free the pcb due to two references on it. Then it unlocks the pcb. - 1 (or 2) gets wlock on the pcb, runs in_pcbrele_wlocked(), which doesn't report inp as freed, due to 2 (or 1) still helding extra reference on it. The thread tries to do smth with a disconnected pcb and crashes. Submitted by: emeric.poupon@stormshield.eu Reviewed by: glebius@ Sponsored by: Stormshield Tested by: Cassiano Peixoto, Stormshield Modified: stable/10/sys/netinet/in_pcb.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/netinet/in_pcb.c ============================================================================== --- stable/10/sys/netinet/in_pcb.c Wed Dec 2 16:29:36 2015 (r291651) +++ stable/10/sys/netinet/in_pcb.c Wed Dec 2 17:26:37 2015 (r291652) @@ -1148,8 +1148,17 @@ in_pcbrele_wlocked(struct inpcb *inp) INP_WLOCK_ASSERT(inp); - if (refcount_release(&inp->inp_refcount) == 0) + if (refcount_release(&inp->inp_refcount) == 0) { + /* + * If the inpcb has been freed, let the caller know, even if + * this isn't the last reference. + */ + if (inp->inp_flags2 & INP_FREED) { + INP_WUNLOCK(inp); + return (1); + } return (0); + } KASSERT(inp->inp_socket == NULL, ("%s: inp_socket != NULL", __func__));