pfctl segmentation fault in pfctl_optimize.c

[Patrick Lamaiziere]

On Wed, 10 Mar 2021 20:48:15 +0100
"Kristof Provost" <kp at FreeBSD.org> wrote:

Hello,

> > FreeBSD 11.4-RELEASE-p3 / amd64
> >
> > Yesterday while loading a ruleset, pfctl core dumped with a
> > segmentation fault (see gdb below)
> >
> > We are recently using some big tables so may be this is what
> > triggered the problem (?), i can't reproduce this.
> >
> > I've found something on tech at openbsd.org that looks closely related:
> > https://www.mail-archive.com/tech@openbsd.org/msg42870.html
> >  
> At first glance that looks like a sane change, but I can’t reproduce 
> the crash described there.
> 
> Can you reproduce your crash? I try to avoid making changes I can’t 
> write a test for.

No I can't reproduce the problem.

We have two firewalls using carp and they use the same pf.conf and the
same big table (~100K ip addresses) stored in a file /etc/ipblocklist
This file comes from another machine, on change it is send via ssh to
the firewalls and pf.conf is reloaded.

on the first (fucop1)
auth.log.14.bz2:Mar  1 07:20:06 fucop1 sudo: scriptcmd : TTY=unknown ; PWD=/usr/home/scriptcmd ; USER=root ; COMMAND=/bin/cp /tmp/ipblocklist /etc/ipblocklist
auth.log.14.bz2:Mar  1 07:20:08 fucop1 sudo: scriptcmd : TTY=unknown ; PWD=/usr/home/scriptcmd ; USER=root ; COMMAND=/sbin/pfctl -nf /etc/pf.conf
auth.log.14.bz2:Mar  1 07:20:09 fucop1 sudo: scriptcmd : TTY=unknown ; PWD=/usr/home/scriptcmd ; USER=root ; COMMAND=/sbin/pfctl -f /etc/pf.conf

messages:Mar  1 07:20:14 fucop1 kernel: pid 30059 (pfctl), jid 0, uid 0: exited on signal 11 (core dumped)
messages:Mar  1 07:20:14 fucop1 kernel: pid 30058 (sudo), jid 0, uid 0: exited on signal 11

on the second firewall all is good, I see the same commands without problem (no core file, no log) and the datas should be exactly the same.
So I don't have any idea, I'm not sure if pfctl is involved in fact...

I've read the code of pfctl a bit. If pfctl crashes in pfctl_optimize_ruleset, is there a risk to leave pf in a bad state ?
Looks like the rules are sent to pf via ioctl after the optimization so a crash before should be harmless (?). 

We were hit by the fact that shortly after pfctl crashed (5 minutes after), we reloaded the rules without error and then pf
stoped to filter the traffic and was wide open, as if the ruleset was empty. 
So I'm asking if the pfctl crash can be related to this problem, I think not but...

Thanks, regards.