Re: panic in ipfw with recent current

Dmitry Marakasov wrote:
> Hi!
> 
> Just updated to recent current (date=2009.07.30.12.00.00), and had
> a panic in ipfw with minimal network activity (one time the box was
> able to get IP via DHCP and panicked on ssh to another host, next
> time it panicked right while booting). Rebuilding the kernel with
> nooptions IPFIREWALL works nice as a workaround.
> 
> Full text available here:
> http://people.freebsd.org/~amdmi3/ipfw-panic.txt
> 
> (kgdb) bt
> #0  doadump () at pcpu.h:246
> #1  0xc04c0049 in db_fncall (dummy1=1, dummy2=0, dummy3=-1059813280, dummy4=0xe58e0558 "") at /usr/src/sys/ddb/db_command.c:548
> #2  0xc04c042e in db_command (last_cmdp=0xc0ca72bc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445
> #3  0xc04c0567 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> #4  0xc04c223f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229
> #5  0xc088922e in kdb_trap (type=12, code=0, tf=0xe58e0784) at /usr/src/sys/kern/subr_kdb.c:534
> #6  0xc0aea4c6 in trap_fatal (frame=0xe58e0784, eva=28) at /usr/src/sys/i386/i386/trap.c:924
> #7  0xc0aea75a in trap_pfault (frame=0xe58e0784, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:846
> #8  0xc0aeb137 in trap (frame=0xe58e0784) at /usr/src/sys/i386/i386/trap.c:528
> #9  0xc0acf71b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #10 0xc5f80c1c in ipfw_chk (args=0xe58e0a3c) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:2061
> #11 0xc5f815c3 in ipfw_check_in (arg=0x0, m0=0xe58e0b70, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw_pfil.c:135
> #12 0xc090a071 in pfil_run_hooks (ph=0xc0ceec20, mp=0xe58e0bc4, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:79
> #13 0xc095c93d in ip_input (m=0xc5dcfe00) at /usr/src/sys/netinet/ip_input.c:497
> #14 0xc09094f3 in netisr_dispatch_src (proto=1, source=0, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:917
> #15 0xc09097a4 in netisr_dispatch (proto=1, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:1004
> #16 0xc09031a0 in ether_demux (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:896
> #17 0xc09036a2 in ether_input (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:755
> #18 0xc053de29 in ale_int_task (arg=0xc55fd000, pending=1) at /usr/src/sys/dev/ale/if_ale.c:2581
> #19 0xc089409f in taskqueue_run (queue=0xc574dd00) at /usr/src/sys/kern/subr_taskqueue.c:282
> #20 0xc089428d in taskqueue_thread_loop (arg=0xc55fda2c) at /usr/src/sys/kern/subr_taskqueue.c:403
> #21 0xc08350a9 in fork_exit (callout=0xc08941d4 <taskqueue_thread_loop>, arg=0xc55fda2c, frame=0xe58e0d38) at /usr/src/sys/kern/kern_fork.c:838
> #22 0xc0acf790 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
> 


found the fix I think..

in line 2061 of ip_fw2.c in the crhold()
the argument should be pcb->inp_cred, not inp->cred

2059        if (pcb != NULL) {
2060              *uc = crhold(inp->inp_cred); <--s/inp/pcb/
2061              *ugid_lookupp = 1;
2062        }

  The change that brought in the bug was:

   SVN rev 194498 on 2009-06-19 17:10:35Z by brooks

as part of a bigger change sweep.
unfortunatly it included this typo/bug

an incoming syn, or unexpected UDP packet will not have a 
pre-exisiting pcb/socket so inp this will be NULL and so
will pcb. Unfortunalty we only test pcb against beign null.
The old code here also used pcb.