On Wednesday 24 August 2005 19:38, Daniel Hartmeier wrote: > 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)...
ifconfig name is propagated as old_name interface disappears, new_name
interface arrives and there should not be a problem. The concern raised
above is addressed by an additional:
#ifdef __FreeBSD__
if (p->pfik_rules > 0 || p->pfik_states > 0) {
/* move back to the dummy group */
p->pfik_parent = pfi_dummy;
p->pfik_flags &= ~PFI_IFLAG_INSTANCE;
pfi_dummy->pfik_addcnt++;
TAILQ_INSERT_TAIL(&pfi_dummy->pfik_grouphead, p,
pfik_instances);
return (0);
}
#endif
a bit further down on pfi_maybe_destroy. Moreover the trace suggests that
this isn't a kif related problem, but a state tree inconsistency.
Pawel, what version are you running? Can you provide $FreeBSD$ for pf.c and
if_pfsync.c [if compiled in], please?
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpm9o034cH0i.pgp
Description: PGP signature
