NetBSD Problem Report #18338

Received: (qmail 29731 invoked by uid 605); 19 Sep 2002 20:48:12 -0000
Message-Id: <200209192048.g8JKm8qn000390@noc.untraceable.net>
Date: Thu, 19 Sep 2002 16:48:08 -0400 (EDT)
From: Andrew Brown <atatat@atatdot.net>
Sender: gnats-bugs-owner@netbsd.org
Reply-To: Andrew Brown <atatat@atatdot.net>
To: gnats-bugs@gnats.netbsd.org
Subject: gre use in -current causes kernel panic
X-Send-Pr-Version: 3.95

>Number:         18338
>Category:       kern
>Synopsis:       gre use in -current causes kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 19 20:49:01 +0000 2002
>Closed-Date:    
>Last-Modified:  Thu Sep 19 21:25:00 +0000 2002
>Originator:     TheMan
>Release:        1.6G (entire system rebuilt from sources as of 20020901)
>Organization:
none
>Environment:

System: NetBSD cafebabe 1.6G NetBSD 1.6G (SEVENTEEN) #2: Thu Sep  5 17:46:37 EDT 2002     root@cafebabe:/usr/src/sys/arch/i386/compile/SEVENTEEN i386

>Description:

pinging the remote inner address on a gre tunnel causes a kernel panic
with this message:

	panic: m_copym: m == 0

gdb reports the backtrace as follows:

(gdb) bt
#0  0x1 in ?? ()
#1  0xc02461df in cpu_reboot (howto=256, bootstr=0x0)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../arch/i386/i386/machdep.c:2209
#2  0xc01982ff in panic ()
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/subr_prf.c:253
#3  0xc01a6460 in m_copym0 (m=0x0, off0=1500, len=1480, wait=1, deep=0)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_mbuf.c:404
#4  0xc01a63c4 in m_copym (m=0xc0409500, off0=1500, len=1480, wait=1)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_mbuf.c:374
#5  0xc01ed324 in ip_output (m0=0xc0409500)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/ip_output.c:708
#6  0xc01c8f9b in gre_output (ifp=0xc0457400, m=0xc0409500, dst=0xc045e024, 
    rt=0xc045f630)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../net/if_gre.c:341
#7  0xc01ed086 in ip_output (m0=0xc0409500)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/ip_output.c:636
#8  0xc01f4941 in rip_output (m=0xc0409500)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/raw_ip.c:373
#9  0xc01f4d95 in rip_usrreq (so=0xc045d000, req=9, m=0xc0409500, 
    nam=0xc0409d00, control=0x0, p=0xc39d93bc)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/raw_ip.c:635
#10 0xc01a8f38 in sosend (so=0xc045d000, addr=0xc0409d00, uio=0xc39e6ec0, 
    top=0xc0409500, control=0x0, flags=0)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_socket.c:748
#11 0xc01abfef in sendit (p=0xc39d93bc, s=3, mp=0xc39e6f24, flags=0, 
    retsize=0xc39e6f78)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_syscalls.c:512
#12 0xc01abdb2 in sys_sendto (p=0xc39d93bc, v=0xc39e6f80, retval=0xc39e6f78)
    at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_syscalls.c:398
#13 0xc024c20b in syscall_plain (frame={tf_gs = 31, tf_fs = 31, tf_es = 31, 
      tf_ds = 31, tf_edi = 134751708, tf_esi = 84, tf_ebp = -1077945452, 
      tf_ebx = 4, tf_edx = 5, tf_ecx = -1, tf_eax = 133, tf_trapno = 3, 
      tf_err = 2, tf_eip = 134640127, tf_cs = 23, tf_eflags = 659, 
      tf_esp = -1077945528, tf_ss = 31, tf_vm86_es = 0, tf_vm86_ds = 0, 
      tf_vm86_fs = 0, tf_vm86_gs = 0})
    at /usr/src/sys/arch/i386/compile/COWS/../../../../arch/i386/i386/syscall.c:151

m is indeed 0 there, but m_copym() called m_copym0() with a non-null
argument.

(gdb) up
#3  0xc01a6460 in m_copym0 (m=0x0, off0=1500, len=1480, wait=1, deep=0) at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_mbuf.c:404
404                             panic("m_copym: m == 0");
(gdb) print m
$1 = (struct mbuf *) 0x0
(gdb) up 
#4  0xc01a63c4 in m_copym (m=0xc0409500, off0=1500, len=1480, wait=1) at /usr/src/sys/arch/i386/compile/COWS/../../../../kern/uipc_mbuf.c:374
374             return m_copym0(m, off0, len, wait, 0); /* shallow copy on M_EXT */
(gdb) print m
$2 = (struct mbuf *) 0xc0409500
(gdb) print m->m_hdr.mh_next
$3 = (struct mbuf *) 0x0
(gdb) 

so i don't know.  i'm not (yet) a networking guru.

>How-To-Repeat:

run this script:

	#!/bin/sh
	li=206.223.36.155
	ri=192.168.0.13
	lo=206.223.36.144
	ro=66.65.59.120
	ifconfig lo0 127.0.0.1
	ifconfig ep0 206.223.36.144/25
	route add default 206.223.36.132
	ifconfig gre0 create
	ifconfig gre0 $li $ri
	ifconfig gre0 tunnel $lo $ro
	route add $li 127.0.0.1
	route add -net 192.168.0.0 -netmask 0xffffff00 $ri
	echo now ping $ri

and then ping the address as it tells you.

>Fix:

sorry...i don't know such stuff.

>Release-Note:
>Audit-Trail:

From: Andrew Brown <atatat@atatdot.net>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/18338: gre use in -current causes kernel panic
Date: Thu, 19 Sep 2002 16:52:05 -0400

 >>Number:         18338
 >>Category:       kern
 >>Synopsis:       gre use in -current causes kernel panic

 so, of course, i forgot to mention that in

 	ftp://ftp.daemon.org/outgoing/gre-crash/

 you can find a kernel dump and the corresponding kernel, both with and
 without gdb foo.  oh, and the script.

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."

From: Martin Husemann <martin@duskware.de>
To: Andrew Brown <atatat@atatdot.net>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/18338: gre use in -current causes kernel panic
Date: Thu, 19 Sep 2002 23:12:29 +0200

 > #5  0xc01ed324 in ip_output (m0=0xc0409500)
 >     at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/ip_output.c:708

 This for loop is entered because ip->ip_len is in host byte order, while
 it is supposed to be in network byte order. The code then tries to fragment
 the much too large (because of wrong byte order) packet and runs out of data
 on the mbuf chain.

 I have no idea where the ip_len field in the IP header is swapped though.

 Martin


From: Andrew Brown <atatat@atatdot.net>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/18338: gre use in -current causes kernel panic
Date: Thu, 19 Sep 2002 17:24:48 -0400

 >> #5  0xc01ed324 in ip_output (m0=0xc0409500)
 >>     at /usr/src/sys/arch/i386/compile/COWS/../../../../netinet/ip_output.c:708
 >
 >This for loop is entered because ip->ip_len is in host byte order, while
 >it is supposed to be in network byte order. The code then tries to fragment
 >the much too large (because of wrong byte order) packet and runs out of data
 >on the mbuf chain.
 >
 >I have no idea where the ip_len field in the IP header is swapped though.

 the code path *leading* to that crosses rip_output() because i ran
 ping.  ping generates raw datagrams.  maybe the ip_len field was
 swapped too many times or not enough (in conjunction with rev 1.100 of
 ip_output.c)?

 -- 
 |-----< "CODE WARRIOR" >-----|
 codewarrior@daemon.org             * "ah!  i see you have the internet
 twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
 werdna@squooshy.com       * "information is power -- share the wealth."
>Unformatted:

Home	PR Database Search