From owner-freebsd-current@freebsd.org Thu Nov 5 17:39:26 2015 Return-Path: Delivered-To: freebsd-current@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 75330A2779E for ; Thu, 5 Nov 2015 17:39:26 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (eris.uffner.com [71.162.143.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "eris.uffner.com", Issuer "Uffner.com CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E6D51135 for ; Thu, 5 Nov 2015 17:39:25 +0000 (UTC) (envelope-from tom@uffner.com) Received: from discordia.uffner.com (discordia.uffner.com [10.69.69.61]) (authenticated bits=0) by eris.uffner.com (8.14.9/8.14.9) with ESMTP id tA5HdMPn051906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Nov 2015 12:39:22 -0500 (EST) (envelope-from tom@uffner.com) Message-ID: <563B944A.50905@uffner.com> Date: Thu, 05 Nov 2015 12:39:22 -0500 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: FreeBSD-Current Subject: Re: r289932 causes pf reversion - breaks rules with broadcast destination References: <563AB177.6030809@uffner.com> In-Reply-To: <563AB177.6030809@uffner.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 17:39:26 -0000 Tom Uffner wrote: > Commit r289932 causes pf rules with broadcast destinations (and some but not > all rules after them in pf.conf) to be silently ignored. This is bad. > I do not understand the pf code well enough to see why this change caused > the breakage, but I suspect that it might expose some deeper problem and > should not simply be reverted. OK, so here is why I don't want to simply back this out and have a "working" firewall again: Apparently PF_ANEQ was prone to false positives when comparing IPv4 addrs. This is what r289932 and r289940 fixed. For IPv4 it does not matter where in bits 32-127 the address mismatch occurs or what order the garbage data is tested. That is all the paren fix in r289940 changes. It might be relevant for v6, but doesn't matter here. So, if my rule was "working" due to false positive in a comparison that has now been fixed, how many other address comparisons were affected by this error? There are 36 occurrences of PF_ANEQ in pf.c and 2 in if_pfsync.c About half of them appear to be testing IPv4 addresses. How many of them may have been influenced by uninitialized data returning a false positive result?