kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?)

Daniel Hartmeier daniel at
Mon Jun 4 10:08:34 UTC 2012

I think I found what might happen in your case. When reading the
ipfilter hook previously, I thought that it would return quickly due to
fr_running not being enabled, but it's not an 'enabled' flag as set
manually with pfctl -e!

If you compile in ipfilter (as your kernel config does), it will run
a lot of code, even if you don't enable it in rc.conf and configure a

I noticed that in all your traces so far, the packets always have ip_p=1
(ICMP) and a non-minimal length.

There's a very suspicious m_pulldown() call here

			  for len > MHLEN (around what, 150?)

where fr_pullup() subsequently even does this

                while (M_LEN(m) == 0) {
                        m = m->m_next;

i.e. it seems to explicitely deal with the case where the mbuf starts
with m_len==0 segments.

The problem is, nothing else does, neither other pfil consumers (like
ipfw or pf) nor bridge or any other networking code I can find.
This could also explain the effects in ipfw (not updating byte order)
and pf (panic you originally reported).

There are barely any other m_pulldown() calls in the kernel, especially
with offp=NULL, and its source is full of warning comments, see
/usr/src/sys/kern/uipc_mbuf2.c. So I'm not sure if it's being used
wrongly (ignoring its return value certainly looks wrong), or if it
shouldn't be used at all.

You can possibly trigger the problem by provoking an ICMP TTL exceeded
error of size 150-200, either with traceroute -I packetlen or by
manually crafting it (with dnet from ports or such).

Alternatively, I suspect the problem will no longer show when you
disable ipfilter.


More information about the freebsd-pf mailing list