Date: Fri, 10 Apr 2009 15:04:20 +0100 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org, Mikolaj Golub <to.my.trociny@gmail.com> Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Message-ID: <200904101604.20987.max@love2party.net> In-Reply-To: <200904101150.n3ABo30b066303@freefall.freebsd.org> References: <200904101150.n3ABo30b066303@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 10 April 2009 13:50:03 Mikolaj Golub wrote:
> The following reply was made to PR kern/130977; it has been noted by GNAT=
S.
>
> From: Mikolaj Golub <to.my.trociny@gmail.com>
> To: bug-followup@FreeBSD.org,darkibot@gmail.com
> Cc:
> Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user
> connect to VPN server Date: Fri, 10 Apr 2009 14:42:59 +0300
>
> The problem here (as in kern/131310 and may be in some other reports) is
> that net/if.c:if_attach() when attaching interface adds it to default gro=
up
> ALL calling if_addgroup(ifp, IFG_ALL). But when interface is removed (in
> this case ng, but the same thing occurs for other interfaces too, e.g. I
> checked it for tap) the reference to it does not removed from
> ifgl_group.ifg_members list.
>
> The simple test can be used to confirm this:
>
> 1) add interface (e.g. starting mpd);
>
> 2) run kgdb and find reference to ng interface in the list
> ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members
>
> E.g. in my case it is:
>
> (kgdb) p
> *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.if=
gm
>_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $1 =3D {if_s=
oftc
> =3D 0xc4e180c0, if_l2com =3D 0x0, if_link =3D {tqe_next =3D 0x0, tqe_prev=
=3D
> 0xc4264808}, if_xname =3D "ng0", '\0' <repeats 12 times>, if_dname =3D
> 0xc4bd60d9 "ng", if_dunit =3D 0, if_addrhead =3D { tqh_first =3D 0xc4ba4e=
00,
> tqh_last =3D 0xc4ba4e60}, if_klist =3D {kl_list =3D {slh_first =3D 0x0}, =
kl_lock =3D
> 0xc07abb00 <knlist_mtx_lock>, kl_unlock =3D 0xc07abb30 <knlist_mtx_unlock=
>,
> ...
>
> 3) remove ng interface (e.g. stopping mpd). Check that in the list
> ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members we still have
> the reference to already removed interface:
>
> (kgdb) p
> *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.if=
gm
>_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $2 =3D {if_s=
oftc
> =3D 0xdeadc0de, if_l2com =3D 0xdeadc0de, if_link =3D {tqe_next =3D 0xdead=
c0de,
> tqe_prev =3D 0xdeadc0de}, if_xname =3D "=DE=C0=AD=DE=DE=C0=AD=DE=DE=C0=AD=
=DE=DE=C0=AD=DE", if_dname =3D
> 0xdeadc0de <Error reading address 0xdeadc0de: Bad address>, if_dunit =3D
> -559038242, if_addrhead =3D {tqh_first =3D 0xdeadc0de, tqh_last =3D 0xdea=
dc0de},
> if_klist =3D {kl_list =3D { slh_first =3D 0xdeadc0de}, kl_lock =3D 0xdead=
c0de,
> kl_unlock =3D 0xdeadc0de, kl_locked =3D 0xdeadc0de,
>
> If you repeat this process many times you will have the long least of
> invalid ifgm_ifp references.
>
> pf traverses the list
> ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members in
> pfi_table_update and calls pfi_instance_add() with nonvalid ifgm_ifp
> argument and the system panics trying to access invalid memory.
>
> I don't know if this correct solution but adding if_delgroup(ifp, IFG_AL=
L)
> to sys/net/if.c:if_detach() fixes the problem for me.
>
> --- sys/net/if.c.orig 2009-04-01 10:53:55.000000000 +0300
> +++ sys/net/if.c 2009-04-10 12:38:14.000000000 +0300
> @@ -846,6 +846,7 @@ if_detach(struct ifnet *ifp)
> mtx_destroy(&ifp->if_snd.ifq_mtx);
> IF_AFDATA_DESTROY(ifp);
> splx(s);
> + if_delgroup(ifp, IFG_ALL);
> }
>
> /*
Good catch! Thank you very much. I'll commit your fix shortly after some=
=20
testing and will see that we can get it into 7.2
=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904101604.20987.max>