pf silently ignores certain rules
FreeBSD-SA-26:09.pf · CVE-2026-4748
Our decision for FreeSense
FreeBSD corrected this on 2026-03-25, before the FreeBSD source pin of every FreeSense version.
- Advisory: corrected 2026-03-25
- FreeSense 1.0 pin: e004ff15f87e (2026-08-03)
- FreeSense 1.1 pin: a52c50b4b7c2 (2026-10-04)
- FreeSense 1.2 pin: a52c50b4b7c2 (2026-10-04)
By FreeSense version
| Version | Status | FreeBSD pin |
|---|---|---|
| FreeSense 1.01.0.7 · frozen, no further fixes | FixedFreeBSD pin of 2026-08-03 | 2026-08-03e004ff15 |
| FreeSense 1.11.1.9 | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
| FreeSense 1.21.2.0-DEVELOPMENT | FixedFreeBSD pin of 2026-10-04 | 2026-10-04a52c50b4 |
Workaround
Only systems using the pf firewall are affected. The operator can determine if a specific system is affected by reloading the configuration verbosely: # pfctl -vf /etc/pf.conf | grep already As a workaround, affected rules can be rewritten, e.g., by using tables or multiple rules instead of address ranges. Another option is to add labels to rules to make them unique.
What FreeBSD says
A regression in the way hashes were calculated caused rules containing the address range syntax (x.x.x.x - y.y.y.y) that only differ in the address range(s) involved to be silently dropped as duplicates. Only the first of such rules is actually loaded into pf. Ranges expressed using the address[/mask-bits] syntax were not affected. Some keywords representing actions taken on a packet-matching rule, such as 'log', 'return tll', or 'dnpipe', may suffer from the same issue. It is unlikely that users have such configurations, as these rules would always be redundant. The verification described in "IV. Workaround" below will find these as well.
Impact
Affected rules are silently ignored, which can lead to unexpected behaviour including over- and underblocking.
Excerpt from the FreeBSD advisory. Read the original for the full text and the fix.