Date: Wed, 24 Aug 2005 19:38:24 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-pf@freebsd.org Subject: Re: PF doesn't work with changed interfaces names. Message-ID: <20050824173824.GA25807@insomnia.benzedrine.cx> In-Reply-To: <20050824150914.GA1603@garage.freebsd.pl> References: <20050824150914.GA1603@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 24, 2005 at 05:09:14PM +0200, Pawel Jakub Dawidek wrote:
> When we change interface name with:
>
> # ifconfig fxp0 name net0
>
> and we add a firewall rule, restart pf, remove the rule, restart pf, we got:
>
> Fatal trap 12: page fault while in kernel mode
The rule might have created an interface-bound state entry on fxp0. I
don't know off-hand how 'ifconfig name' interacts with pf_if.c pfi_*()
functions, but if it destroys the kif object of fxp0 (and creates a new
one for net0), there might be a problem in pf_if.c pfi_maybe_destroy()
#ifdef __FreeBSD__
if ((p->pfik_flags & (PFI_IFLAG_ATTACHED | PFI_IFLAG_GROUP)) ||
((p->pfik_rules > 0 || p->pfik_states > 0) &&
(p->pfik_flags & PFI_IFLAG_PLACEHOLDER) == 0))
#else
if ((p->pfik_flags & (PFI_IFLAG_ATTACHED | PFI_IFLAG_GROUP)) ||
p->pfik_rules > 0 || p->pfik_states > 0)
#endif
return (0);
The non-FreeBSD version strictly returns when the pfi_kif object still
contains state entries, but the FreeBSD version might be free'ing the
object when it still contains state entries. Those state entries point
back to the pfi_kif object that contains them. If this happens, you
might see exactly the crash you describe, i.e. pf_state_compare_*() then
tries to access the no-longer-existing pfi_kif object to traverse state
entries in there, accessing invalid memory.
I have to study the use of PFI_IFLAG_PLACEHOLDER more, maybe Max has an
idea what goes wrong there on interface name changes (ifconfig name)...
As a short-term workaround, I think disabling pf and flusing the state
table (pfctl -d; pfctl -Fs) before the ifconfig invokation would prevent
the panic.
Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050824173824.GA25807>