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

Daniel Hartmeier daniel at
Mon Jun 4 10:10:20 UTC 2012

The following reply was made to PR kern/168190; it has been noted by GNATS.

From: Daniel Hartmeier <daniel at>
To: Joerg Pulz <Joerg.Pulz at>
Cc: bug-followup at, freebsd-pf at
Subject: Re: kern/168190: [pf] panic when using pf and route-to (maybe: bad fragment handling?)
Date: Mon, 4 Jun 2012 12:08:29 +0200

 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