Date: Thu, 05 Nov 2015 12:39:22 -0500 From: Tom Uffner <tom@uffner.com> To: FreeBSD-Current <freebsd-current@FreeBSD.org> Subject: Re: r289932 causes pf reversion - breaks rules with broadcast destination Message-ID: <563B944A.50905@uffner.com> In-Reply-To: <563AB177.6030809@uffner.com> References: <563AB177.6030809@uffner.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?563B944A.50905>