Bug 29583
| Summary: | 4.4-PREREL/ipf 3.4.20: 'to' rule with tun causes crash | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Thomas Quinot <thomas> |
| Component: | kern | Assignee: | Darern Reed <darrenr> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.4-PRERELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Thomas Quinot
2001-08-09 23:40:01 UTC
Responsible Changed From-To: freebsd-bugs->darrenr Darren is the ipf maintainer Darren,
I have just re-tested the problem described in FreeBSD PR kern/29583
('to' redirection based on source IP address causes crash). On a
4.4-STABLE cvsupped today, with your 3.4.22 IPFilter release, I still
obtained an instantaneous reboot as soon as a packet matching the
rule went out of the machine.
Thomas.
--
Thomas.Quinot@Cuivre.FR.EU.ORG
In a previous email, I wrote: > I have just re-tested the problem described in FreeBSD PR kern/29583 > ('to' redirection based on source IP address causes crash). On a > 4.4-STABLE cvsupped today, with your 3.4.22 IPFilter release, I still > obtained an instantaneous reboot as soon as a packet matching the > rule went out of the machine. Tried 3.4.23 on 4.5-RC. There is definitely an improvement: the system does not crash anymore -- it hangs instead, stuck in a tight loop in the kernel. Fortunately, I was able to drop into DDB and make it panic, so we now have a clean crash dump, and an identification of the point where it is hanging. See attached typescript... Please let me know if there is anything I can do to help tracking this problem down. Script started on Tue Jan 15 22:59:18 2002 # gdb -k /usr/obj/usr/src/sys/MELUSINE/kernel.debug vmcore.0 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 4194304 initial pcb at 3555e0 panicstr: from debugger panic messages: --- panic: from debugger syncing disks... 16 done Uptime: 5m45s dumping to dev #ad/0x20009, offset 262168 dump ata0: resetting devices .. done [...] --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473 473 if (dumping++) { (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473 #1 0xc0174a81 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:313 #2 0xc0174e71 in panic (fmt=0xc02d9ae4 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:581 #3 0xc014aa31 in db_panic (addr=-1070927120, have_addr=0, count=-1, modif=0xd9c5bb78 "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc014a9d0 in db_command (last_cmdp=0xc0315c24, cmd_table=0xc0315a64, aux_cmd_tablep=0xc034e058) at /usr/src/sys/ddb/db_command.c:333 #5 0xc014aa96 in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 #6 0xc014cbc3 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 #7 0xc02af09a in kdb_trap (type=3, code=0, regs=0xd9c5bc98) at /usr/src/sys/i386/i386/db_interface.c:158 #8 0xc02bbd94 in trap (frame={tf_fs = -641400816, tf_es = 16, tf_ds = 16, tf_edi = -1070175424, tf_esi = 0, tf_ebp = -641352480, tf_isp = -641352508, tf_ebx = 134, tf_edx = 4325376, tf_ecx = 32, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1070927120, tf_cs = 8, tf_eflags = 582, tf_esp = -1070567809, tf_ss = -1070581751}) at /usr/src/sys/i386/i386/trap.c:574 #9 0xc02af2f0 in Debugger (msg=0xc0303809 "manual escape to debugger") at machine/cpufunc.h:67 #10 0xc02aabb6 in scgetc (sc=0xc036c540, flags=2) at /usr/src/sys/dev/syscons/syscons.c:3148 #11 0xc02a73c5 in sckbdevent (thiskbd=0xc0365240, event=0, arg=0xc036c540) at /usr/src/sys/dev/syscons/syscons.c:616 ---Type <return> to continue, or q <return> to quit--- #12 0xc029ef9e in atkbd_intr (kbd=0xc0365240, arg=0x0) at /usr/src/sys/dev/kbd/atkbd.c:462 #13 0xc02c9140 in atkbd_isa_intr (arg=0xc0365240) at /usr/src/sys/isa/atkbd_isa.c:140 #14 0xc0172e8e in add_interrupt_randomness (vsc=0xc036bdcc) at /usr/src/sys/kern/kern_random.c:245 #15 0xc01952b4 in sbappendaddr (sb=0xd7ccdf0c, asa=0xc031e020, m0=0xc1826500, control=0xc1826500) at /usr/src/sys/kern/uipc_socket2.c:657 #16 0xc019837e in uipc_send (so=0xd7ccd740, flags=0, m=0xc1826500, nam=0x0, control=0x0, p=0xd6ddac20) at /usr/src/sys/kern/uipc_usrreq.c:300 #17 0xc0192ce7 in sosend (so=0xd7ccd740, addr=0x0, uio=0xd9c5bec4, top=0xc1826500, control=0x0, flags=0, p=0xd6ddac20) at /usr/src/sys/kern/uipc_socket.c:611 #18 0xc019662d in sendit (p=0xd6ddac20, s=3, mp=0xd9c5bf04, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:583 #19 0xc0196732 in sendto (p=0xd6ddac20, uap=0xd9c5bf80) at /usr/src/sys/kern/uipc_syscalls.c:636 #20 0xc02bc6ba in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077943328, tf_esi = 672154340, tf_ebp = -1077943412, tf_isp = -641351724, tf_ebx = 672333636, tf_edx = 97, tf_ecx = -1077942260, tf_eax = 133, tf_trapno = 22, tf_err = 2, tf_eip = 672036456, tf_cs = 31, tf_eflags = 647, tf_esp = -1077943472, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1157 #21 0xc02afe55 in Xint0x80_syscall () ---Type <return> to continue, or q <return> to quit--- #22 0x281046d7 in ?? () #23 0x28104351 in ?? () #24 0x80685da in ?? () #25 0x80665cb in ?? () #26 0x80668c9 in ?? () #27 0x8065eb9 in ?? () #28 0x8065986 in ?? () #29 0x806117f in ?? () #30 0x80515c9 in ?? () #31 0x805cf4f in ?? () #32 0x805cc28 in ?? () #33 0x8049a57 in ?? () (kgdb) fr 15 #15 0xc01952b4 in sbappendaddr (sb=0xd7ccdf0c, asa=0xc031e020, m0=0xc1826500, control=0xc1826500) at /usr/src/sys/kern/uipc_socket2.c:657 657 sballoc(sb, n); (kgdb) list 652 n->m_next = m0; /* concatenate data to control */ 653 else 654 control = m0; 655 m->m_next = control; 656 for (n = m; n; n = n->m_next) 657 sballoc(sb, n); 658 n = sb->sb_mb; 659 if (n) { 660 while (n->m_nextpkt) 661 n = n->m_nextpkt; (kgdb) print n $1 = (struct mbuf *) 0xc1826500 (kgdb) print n->m_hdr.mh_next $3 = (struct mbuf *) 0xc1826500 (kgdb) print *sb $5 = {sb_cc = 1983817059, sb_hiwat = 4096, sb_mbcnt = 1676293120, sb_mbmax = 32768, sb_lowat = 1, sb_mb = 0xc1853f00, sb_sel = {si_pid = 0, si_note = {slh_first = 0x0}, si_flags = 0}, sb_flags = 0, sb_timeo = 0} (kgdb) quit -- Thomas.Quinot@Cuivre.FR.EU.ORG Guido van Rooij provided the following explanation for the cause of the crashes: ----- Forwarded message from Guido van Rooij <guido@gvr.org> ----- Date: Wed, 16 Jan 2002 16:18:14 +0100 From: Guido van Rooij <guido@gvr.org> Cc: ipfilter@coombs.anu.edu.au Subject: Re: Routing based on source address problem (with request to Darren) On Wed, Jan 16, 2002 at 03:40:35PM +0100, Thomas Quinot wrote: > All the details are in PR kern/29583, with the exact ipf rules involved > and a few debug traces: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/29583 > The most important part of PR is the following rule: block out log quick on tun0 to tun1:10.3.0.1 from VPN.IP.ADDR.ESS/32 to any group 11 Darren: I think IPfilter should forbid blocking of a packet using the 'to' directive. Explanation: "to" will ensure that the packet gets fastrouted. This means the mbuf will be queued at the specific interface queue to be sent out. If you block the packet, it will be freed (not sure if that is in ipfilter or in ip_input or whatever). This means we have a race: the freeing versus the use in the tun1 interface queue. I guess that is the problem here. [...] ----- End forwarded message ----- A work-around was to rewrite the aforementioned rule as: pass out log quick on tun0 to tun1:10.3.0.1 from VPN.IP.ADDR.ESS/32 to any group 11 which, contrary to what is written in the IPF-HOWTO, won't panic the machine. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG State Changed From-To: open->feedback please test this with -stabel or -current as of today. many changes have been made which more than likely stop these panics (I hope!) Le 2002-04-27, darrenr@FreeBSD.org écrivait : > please test this with -stabel or -current as of today. many changes > have been made which more than likely stop these panics (I hope!) Confirmed. IPF 3.4.27, MFC'd in FreeBSD 4-STABLE, does not exhibit this crash anymore. Thanks! -- Thomas.Quinot@Cuivre.FR.EU.ORG State Changed From-To: feedback->closed fixed in both -stable and -current |
