Date: Thu, 22 Jul 2004 04:56:12 +0200 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Subject: Re: LORs with PF Message-ID: <200407220456.19592.max@love2party.net> In-Reply-To: <20040721213712.GL8753@mail.evip.pl> References: <20040721213712.GL8753@mail.evip.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-02=_Tzy/AjVuxcrYf/F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 July 2004 23:37, Wiktor Niesiobedzki wrote: > Hi, > > I don't think, it was reported yet, but here it goes: > > lock order reversal > 1st 0xc0632c80 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf.c:5822 2nd 0xc066638c tcp (tcp) @ > /usr/src/sys/contrib/pf/net/pf.c:2420 > KDB: stack backtrace: > kdb_backtrace(c05f529a,c066638c,c05f4e21,c05f4e21,c05e7e3f) at > kdb_backtrace+0x2e witness_checkorder(c066638c,9,c05e7e3f,974,104) at > witness_checkorder+0x672 _mtx_lock_flags(c066638c,0,c05e7e3f,974,c1893230) > at _mtx_lock_flags+0x80 > pf_socket_lookup(cb9659b4,cb9659b8,2,cb965a70,c14fad00) at > pf_socket_lookup+0xb4 pf_test_tcp(cb965a20,cb965a18,2,c14fad00,c1475100) = at > pf_test_tcp+0x529 pf_test(2,c10d8014,cb965b00,c15276a0,c0665ee0) at > pf_test+0x4a3 > pf_check_out(0,cb965b00,c10d8014,2,c1475100) at pf_check_out+0x5b > pfil_run_hooks(c0665ee0,cb965bc0,c10d8014,2,c04e8a70) at > pfil_run_hooks+0xca ip_output(c1475100,0,0,1,0) at ip_output+0x66d > ip_forward(c1475100,0,0,1,0) at ip_forward+0x37d > ip_input(c1475100,0,c05fad20,96,c0665598) at ip_input+0x65d > netisr_processqueue(c0665598,0,c05fad20,fe,c10d62c0) at > netisr_processqueue+0x8e swi_net(0,0,c05ef737,263,c063ae60) at swi_net+0x= a3 > ithread_loop(c10dd400,cb965d48,c05ef52e,328,c10dd400) at ithread_loop+0x1= 72 > fork_exit(c04ad4c0,c10dd400,cb965d48) at fork_exit+0xc2 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip =3D 0, esp =3D 0xcb965d7c, ebp =3D 0 --- Ture, this was not reported earlier but is wellknown with ipfw. It exists a= s=20 checking UID/GID in an IP-level firewall is a layer violation. The original= =20 LO comes from the following path: proto_output: lock PCB -> ip_output(... pcb) -> pflil_hooks -> pf: lock = pf vs. the above ip_input -> pfil_hooks -> pf: lock pf -> check socket credentials: lock = PCB It is not possible to drop the pf lock for lookup as this happens during=20 ruleset evaluation (and no other thread should be allowed to modify the=20 rules). I know that people are looking for a solution for ipfw, I have no=20 idea at the moment and hence am very happy for any suggestion. =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 --Boundary-02=_Tzy/AjVuxcrYf/F Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBA/yzTXyyEoT62BG0RAvLIAKCCEwZ3O/i4yoH+Ct18ZDyBuohACwCeMKaD PIaMFZ35+5qp/tWgrTq1vHA= =rqVF -----END PGP SIGNATURE----- --Boundary-02=_Tzy/AjVuxcrYf/F--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407220456.19592.max>