From owner-freebsd-bugs@FreeBSD.ORG Fri May 20 13:40:03 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0E11065672 for ; Fri, 20 May 2011 13:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 251A58FC15 for ; Fri, 20 May 2011 13:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4KDe3gJ022122 for ; Fri, 20 May 2011 13:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4KDe3mO022121; Fri, 20 May 2011 13:40:03 GMT (envelope-from gnats) Date: Fri, 20 May 2011 13:40:03 GMT Message-Id: <201105201340.p4KDe3mO022121@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/157209: [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 13:40:03 -0000 The following reply was made to PR kern/157209; it has been noted by GNATS. From: Gleb Smirnoff To: Dmitrij Tejblum Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/157209: [patch] locking error in rip6_input() (sys/netinet6/raw_ip6.c) Date: Fri, 20 May 2011 17:34:35 +0400 Dmitrij, On Fri, May 20, 2011 at 12:33:35PM +0000, Dmitrij Tejblum wrote: D> >Fix: D> A possible quick patch is attached; anothe quick possibility would be to remove the unlock. I think deleting INP_RUNLOCK would be more clean in the current code, because in6p_cksum isn't actually protected by INP_RLOCK in the function where it is written, the ip6_raw_ctloutput(). However, in_pcb.h says that in6p_cksum should be protected by inp lock. So may be a thorough fix would be your patch + adding locking to the ip6_raw_ctloutput(). D> Patch attached with submission follows: D> D> --- sys/netinet6/raw_ip6.c 2010-08-31 19:52:12.000000000 +0400 D> +++ sys/netinet6/raw_ip6.c 2011-05-14 00:27:24.000000000 +0400 D> @@ -193,20 +193,20 @@ D> if (!IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) && D> prison_check_ip6(in6p->inp_cred, D> &ip6->ip6_dst) != 0) D> continue; D> } D> + INP_RLOCK(in6p); D> if (in6p->in6p_cksum != -1) { D> V_rip6stat.rip6s_isum++; D> if (in6_cksum(m, proto, *offp, D> m->m_pkthdr.len - *offp)) { D> INP_RUNLOCK(in6p); D> V_rip6stat.rip6s_badsum++; D> continue; D> } D> } D> - INP_RLOCK(in6p); D> /* D> * If this raw socket has multicast state, and we D> * have received a multicast, check if this socket D> * should receive it, as multicast filtering is now D> * the responsibility of the transport layer. D> D> -- Totus tuus, Glebius.