Re: panic in ipfw with recent current

From: Julian Elischer <julian_at_elischer.org>
Date: Thu, 13 Aug 2009 17:00:01 -0700
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.
Received on Thu Aug 13 2009 - 22:00:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC