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.

Affected rules are silently ignored, which can lead to unexpected behaviour including over- and underblocking.

Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic.

Remote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.