Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jul 2006 03:05:59 +0200
From:      Daniel Hartmeier <daniel@benzedrine.cx>
To:        Max Laier <max@love2party.net>
Cc:        Michal Mertl <mime@traveller.cz>, freebsd-stable@freebsd.org, freebsd-pf@freebsd.org
Subject:   Re: Kernel panic with PF
Message-ID:  <20060721010559.GB23227@insomnia.benzedrine.cx>
In-Reply-To: <200607210205.51614.max@love2party.net>
References:  <1153410809.1126.66.camel@genius.i.cz> <200607210205.51614.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote:

> Which proxies are you using?  The "pool_ticket: 1429 != 1430" messages you 
> quote below indicate a synchronization problem within the app talking to pf 
> via ioctl's.  Tickets are used to ensure atomic commits for operations that 
> require more than one ioctl.  If your proxy app runs in parallel it might 
> screw up the internal state and thus leave it undefined afterwards.  I give 
> you that this shouldn't cause a kernel problem, but if we could fix the app 
> we can probably find the right sanity check more easily.

This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE

                        if (((((newrule->action == PF_NAT) ||
                            (newrule->action == PF_RDR) ||
                            (newrule->action == PF_BINAT) ||
                            (newrule->rt > PF_FASTROUTE)) &&
-                           !pcr->anchor[0])) &&
+                           !newrule->anchor)) &&
                            (TAILQ_FIRST(&newrule->rpool.list) == NULL))
                                error = EINVAL;

i.e. the pool must not be empty for routing and translation rules,
except for translation rules that are actually anchor _calls_.

The confusion is between translation rules within anchors
(pcr->anchor[0] != '\0') and calls to anchors' translation rules
(rule->anchor != NULL).

If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't
using it at all), AND is trying to add/update a rule that requires at
least one replacement address but contains an empty list, then this
would cause the panic seen when that rule later matches a packet.

This needs fixing in OpenBSD as well.

Michal, can you please confirm that the patch above fixes the panic?
The proxy will still misbehave and cause the log messages (one more
EINVAL in this case ;), but the kernel shouldn't crash anymore.

Thanks for the excellent bug report!

Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060721010559.GB23227>