kern/42089: NetBSD 5.0.1 panics in tcp6_input -> tcp_input -> m_freem

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         42089
>Category:       kern
>Synopsis:       NetBSD 5.0.1 panics in tcp6_input -> tcp_input -> m_freem
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 18 08:05:01 +0000 2009
>Originator:     Andreas Gustafsson
>Release:        NetBSD 5.0.1
>Organization:
>Environment:
System: NetBSD guava.gson.org 5.0.1 NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 
01:39:11 UTC 2009 
builds%b8.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
Architecture: i386
Machine: i386
>Description:

My NetBSD 5.0.1 system running under VMware Fusion has suffered
repeated panics since I started using IPv6.  Tracking down the issue
has been hampered by the savecore breakage of PR 41310, but I now
finally managed to get a core dump.  Here's the backtrace:

  #0  0xc0543ab2 in cpu_reboot ()
  #1  0xc0488350 in panic ()
  #2  0xc054679d in trap ()
  #3  0xc010cb80 in calltrap ()
  #4  0xc053ed71 in db_read_bytes ()
  #5  0xc01b2197 in db_get_value ()
  #6  0xc053f60a in db_stack_trace_print ()
  #7  0xc0488325 in panic ()
  #8  0xc054679d in trap ()
  #9  0xc010cb80 in calltrap ()
  #10 0xc04a9c28 in m_freem ()
  #11 0xc0157252 in tcp_input ()
  #12 0xc01591ba in tcp6_input ()
  #13 0xc0196196 in ip6_input ()
  #14 0xc0196961 in ip6intr ()
  #15 0xc046c62c in softint_dispatch ()
  #16 0xc0100e6d in Xsoftintr ()
  #17 0x00000000 in ?? ()

By disassembling the instructions around address 0xc0157252 and
manually correlating them with the tcp_input.c source code, I have
determined that the offending m_freem() call is the one on line 2658
of tcp_input.c 1.291.8.1.

I see that Julian Coleman reported a similar crash in
http://mail-index.netbsd.org/port-sparc64/2008/02/01/msg000065.html
which looks like it may have been ipf related.  My /etc/rc.conf has
ipfilter=YES, and there is both an ipf.conf and an ipf6.conf, but I
was not doing anything to the filters at the time of the crash, just
reading mail over IPv6.  The system is running the GENERIC kernel from
the official 5.0.1 release build.

The crash dump and ipf{6,}.conf are available on request.

>How-To-Repeat:

>Fix: