From owner-freebsd-pf@FreeBSD.ORG Wed Mar 11 08:39:24 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02BCFB5C; Wed, 11 Mar 2015 08:39:24 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA3ED6B7; Wed, 11 Mar 2015 08:39:20 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id B87B81BEBB; Wed, 11 Mar 2015 09:39:16 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id B0F202E24D; Wed, 11 Mar 2015 09:39:16 +0100 (CET) Date: Wed, 11 Mar 2015 09:39:16 +0100 From: Kristof Provost To: freebsd-net@FreeBSD.org Subject: Re: [PATCH] Fix panic with pf fastroute Message-ID: <20150311083916.GQ1975@vega.codepro.be> References: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1426064691-1238-1-git-send-email-kristof@sigsegv.be> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 08:39:24 -0000 Set up a pf ruleset with at least the following rule > pass out fastroute inet6 proto icmp6 all icmp6-type echoreq Send out an icmp6 echo request (i.e. ping6 2001:db8::1). This causes a panic in ip6_output() when comparing the old and new destination addresses (IN6_ARE_ADDR_EQUAL()) just after the netpfil hook. The cause is the fastroute option, which means that the mbuf is handed off to ip6_output() from pf itself and should no longer be processed by the ip6_output() which called pf in the first place. The pf code in pf_route6() neglected to set the mbuf pointer to NULL after the call to ip6_output(). As a result we end up trying to continue processing on an mbuf which has already been freed. --- sys/netpfil/pf/pf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c index b32288b..7c3ddb8 100644 --- a/sys/netpfil/pf/pf.c +++ b/sys/netpfil/pf/pf.c @@ -5470,6 +5470,7 @@ pf_route6(struct mbuf **m, struct pf_rule *r, int dir, struct ifnet *oifp, PF_STATE_UNLOCK(s); m0->m_flags |= M_SKIP_FIREWALL; ip6_output(m0, NULL, NULL, 0, NULL, NULL, NULL); + *m = NULL; return; }