Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Aug 2005 19:59:24 +0200
From:      Max Laier <max@love2party.net>
To:        freebsd-pf@freebsd.org
Subject:   Re: PF doesn't work with changed interfaces names.
Message-ID:  <200508241959.37239.max@love2party.net>
In-Reply-To: <20050824173824.GA25807@insomnia.benzedrine.cx>
References:  <20050824150914.GA1603@garage.freebsd.pl> <20050824173824.GA25807@insomnia.benzedrine.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1792650.bpco6GLWzn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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) =3D=3D 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=20
interface arrives and there should not be a problem.  The concern raised=20
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 =3D pfi_dummy;
                p->pfik_flags &=3D ~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=
=20
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 an=
d=20
if_pfsync.c [if compiled in], please?

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1792650.bpco6GLWzn
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQBDDLWJXyyEoT62BG0RAuSiAKCB+xEK9esbYzo+ptzLKGL23ZyJSQCdHsy6
/UjqqGolc6nxquukKgasUfI=
=nzLO
-----END PGP SIGNATURE-----

--nextPart1792650.bpco6GLWzn--



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