Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 06 Jun 2018 12:07:05 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 228782] Deadlock on pf
Message-ID:  <bug-228782-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228782

            Bug ID: 228782
           Summary: Deadlock on pf
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: t.ermakova@securitycode.ru

Created attachment 194044
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D194044&action=
=3Dedit
fail script

I believe we've faced a problem similar to bug #220217
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220217)

We've configured a machine with FreeBSD-12.0-CURRENT-r334337 software and t=
wo
interfaces (em0, em1).=20
Two pf rules are added:
1) some user rule (it is essential for the crash)
2) a route rule on em1
(The script reproducing the situation is attached -- fail.sh)=20

Trying to establish tcp-connection via route leads to the kernel crash:

panic: rw_rlock: wlock already held for tcpinp @
/usr/src/sys/netinet/in_pcb.c:2092

#0  doadump (textdump=3D0) at pcpu.h:231
#1  0xffffffff8043a51b in db_dump (dummy=3D<value optimized out>,=20
    dummy2=3D<value optimized out>, dummy3=3D<value optimized out>,=20
    dummy4=3D<value optimized out>) at /usr/src/sys/ddb/db_command.c:574
#2  0xffffffff8043a2e9 in db_command (cmd_table=3D<value optimized out>)
    at /usr/src/sys/ddb/db_command.c:481
#3  0xffffffff8043a064 in db_command_loop ()
    at /usr/src/sys/ddb/db_command.c:534
#4  0xffffffff8043d29f in db_trap (type=3D<value optimized out>,=20
    code=3D<value optimized out>) at /usr/src/sys/ddb/db_main.c:252
#5  0xffffffff80bbcd83 in kdb_trap (type=3D3, code=3D0, tf=3D<value optimiz=
ed out>)
    at /usr/src/sys/kern/subr_kdb.c:697
#6  0xffffffff810442c8 in trap (frame=3D0xfffffe0000581c20)
    at /usr/src/sys/amd64/amd64/trap.c:605
#7  0xffffffff8101eddc in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:230
#8  0xffffffff80bbc45b in kdb_enter (why=3D0xffffffff812d4f5f "panic",=20
    msg=3D<value optimized out>) at cpufunc.h:65
#9  0xffffffff80b74db0 in vpanic (fmt=3D<value optimized out>,=20
    ap=3D0xfffffe0000581d90) at /usr/src/sys/kern/kern_shutdown.c:852
#10 0xffffffff80b74b60 in kassert_panic (fmt=3D<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:749
#11 0xffffffff80b70589 in __rw_rlock_int (rw=3D0xfffff80003cf91f8,=20
    file=3D0xffffffff812bc2f4 "/usr/src/sys/netinet/in_pcb.c", line=3D2092)
    at /usr/src/sys/kern/kern_rwlock.c:668
#12 0xffffffff80d04e3c in in_pcblookup_hash ()
    at /usr/src/sys/netinet/in_pcb.c:2092
#13 0xffffffff82821d8f in pf_socket_lookup (direction=3D<value optimized ou=
t>,=20
    pd=3D0xfffffe0000582380, m=3D0xfffff80003b6a400)
    at /usr/src/sys/netpfil/pf/pf.c:2966
#14 0xffffffff82827b33 in pf_test_rule (rm=3D0xfffffe0000582428,=20
    sm=3D0xfffffe0000582440, direction=3D2, kif=3D0xfffff8000342bb00,=20
    m=3D0xfffff80003b6a400, off=3D20, pd=3D0xfffffe0000582380,=20
    am=3D0xfffffe0000582400, rsm=3D0xfffffe00005823f0, inp=3D0x0)
    at /usr/src/sys/netpfil/pf/pf.c:3403
#15 0xffffffff828238b6 in pf_test (dir=3D<value optimized out>,=20
    pflags=3D<value optimized out>, ifp=3D<value optimized out>,=20
    m0=3D0xfffffe0000582558, inp=3D0x0) at /usr/src/sys/netpfil/pf/pf.c:5979
#16 0xffffffff82823591 in pf_test (dir=3D<value optimized out>,=20
    pflags=3D<value optimized out>, ifp=3D<value optimized out>,=20
    m0=3D0xfffffe0000582670, inp=3D<value optimized out>)
    at /usr/src/sys/netpfil/pf/pf.c:5513
#17 0xffffffff8283561d in pf_check_out (arg=3D<value optimized out>,=20
    m=3D0xfffffe0000582670, ifp=3D<value optimized out>,=20
    dir=3D<value optimized out>, flags=3D<value optimized out>,=20
    inp=3D<value optimized out>) at /usr/src/sys/netpfil/pf/pf_ioctl.c:3782
#18 0xffffffff80c9cce7 in pfil_run_hooks (ph=3D<value optimized out>,=20
    mp=3D0xfffffe0000582768, ifp=3D0xfffff80003468800, dir=3D2, flags=3D0,=
=20
    inp=3D0xfffff80003cf91d8) at /usr/src/sys/net/pfil.c:111
#19 0xffffffff80d0dd7a in ip_output (m=3D<value optimized out>,=20
    opt=3D<value optimized out>, ro=3D<value optimized out>,=20
    flags=3D<value optimized out>, imo=3D0x0, inp=3D<value optimized out>)
    at /usr/src/sys/netinet/ip_output.c:120
#20 0xffffffff80d92dee in tcp_output (tp=3D<value optimized out>)
    at /usr/src/sys/netinet/tcp_output.c:1456
#21 0xffffffff80da2f58 in tcp_usr_connect (so=3D0xfffff80003e23358,=20
    nam=3D0xfffff80003048d60, td=3D<value optimized out>)
    at /usr/src/sys/netinet/tcp_usrreq.c:547
#22 0xffffffff80c0f958 in soconnectat (fd=3D-100, so=3D0xfffff80003e23358,=
=20
    nam=3D0x300000012, td=3D0xfffffe0000582a38)
    at /usr/src/sys/kern/uipc_socket.c:1228
#23 0xffffffff80c16e4f in kern_connectat (td=3D0xfffff8000389d000, dirfd=3D=
-100,=20
    fd=3D<value optimized out>, sa=3D0xfffff80003048d60)
    at /usr/src/sys/kern/uipc_syscalls.c:513
#24 0xffffffff80c16d17 in sys_connect (td=3D0xfffff8000389d000,=20
    uap=3D0xfffff8000389d3c0) at /usr/src/sys/kern/uipc_syscalls.c:474
#25 0xffffffff8104504c in amd64_syscall (td=3D0xfffff8000389d000, traced=3D=
0)
    at subr_syscall.c:135
#26 0xffffffff8101f6bd in fast_syscall_common ()
    at /usr/src/sys/amd64/amd64/exception.S:493
#27 0x000000080041084a in ?? ()


The bug #220217 is resolved by passing inpcb pointer to the pfil hook from
enc_hhook.=20
In our case pfil_hook is already called with it (not with NULL). But a furt=
her
method pf_test is called twice - the second time from pf_route with inpcb=
=3DNULL.
This eventually leads to the same deadlock as in bug #220217 case.

I suppose that passing inpcb pointer to pf_route and then to the pf_test can
fix this, but I would really appreciate hearing experts opinion.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



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