From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:14:09 2012 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0416C106564A; Tue, 17 Apr 2012 08:14:09 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9EC8FC12; Tue, 17 Apr 2012 08:14:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3H8E6jQ098838; Tue, 17 Apr 2012 12:14:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3H8E6ab098837; Tue, 17 Apr 2012 12:14:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 12:14:06 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120417081406.GA93887@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-pf@FreeBSD.org Subject: Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 17 Apr 2012 08:14:09 -0000 On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote: E> 2012/4/16 Gleb Smirnoff : E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: E> > T> šOn Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: E> > T> šT> š šI have a vague suspicion on what is happening. Your description of E> > T> šT> šthe problem looks like if a packet processing in the kernel has entered E> > T> šT> šan endless loop. E> > T> šT> E> > T> šT> š šLooking at pf_route() I see such possibility. From OpenBSD we have E> > T> šT> šthis protection against endless looping: E> > T> šT> E> > T> šT> š š š š šif ((*m)->m_pkthdr.pf.routed++ > 3) { E> > T> šT> š š š š š š š š šm0 = *m; E> > T> šT> š š š š š š š š š*m = NULL; E> > T> šT> š š š š š š š š šgoto bad; E> > T> šT> š š š š š} E> > T> šT> E> > T> šT> šIn our code this transforms to: E> > T> šT> E> > T> šT> š š š š šif (pd->pf_mtag->routed++ > 3) { E> > T> šT> š š š š š š š š šm0 = *m; E> > T> šT> š š š š š š š š š*m = NULL; E> > T> šT> š š š š š š š š šgoto bad; E> > T> šT> š š š š š} E> > T> šT> E> > T> šT> šThe root difference between storing the tag on mbuf and on pfdesc E> > T> šT> šis that we lose pfdesc, and thus the tag, when we enter pf_test() E> > T> šT> šrecursively. And pf_route() does this recursion: E> > T> šT> E> > T> šT> š š š š šif (oifp != ifp) { E> > T> šT> š š š š š š š š šif (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { E> > T> šT> š š š š š š š š š š š š šgoto bad; E> > T> šT> š š š š š.... E> > T> E> > T> šOn second look I see that my suspicion may not be true. In the E> > T> šbeginning of pf_test() we do pf_get_mtag() which preserves already E> > T> špresent tag if there is one. E> > E> > Further investigation showed that problem exist when route applied E> > ends in lo0, and packet passes to if_simloop(). There all mtags are E> > stripped from the mbuf, including the pf mtag. Then packet is again E> > processed by ip_input() again entering pf(4), if it again matches E> > a routing rule, then we got an endless loop. E> > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. E> E> That seems like the best fix for this case. In this case crash or freeze is fixed, but still packet is dropped. Example of such rule: pass in on igb0 fastroute proto tcp from any to $localip Anyway, dropping packets is much better than crashing. -- Totus tuus, Glebius.