Subject: kern/30124: FAST_IPSEC: "ping -s 3000" trips assertion failure
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <nathanw@wasabisystems.com>
List: netbsd-bugs
Date: 05/03/2005 21:15:00
>Number:         30124
>Category:       kern
>Synopsis:       FAST_IPSEC: "ping -s 3000" trips assertion failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 03 21:15:00 +0000 2005
>Originator:     Nathan J. Williams
>Release:        NetBSD 3.99.3 (2005-05-02)
>Organization:
	Wasabi Systems, Inc.
>Environment:
	
	
System: NetBSD marvin-the-martian.nathanw.com 3.99.3 NetBSD 3.99.3 (MARVIN) #94: Mon May 2 21:52:17 EDT 2005 nathanw@marvin-the-martian.nathanw.com:/nbsd/src/sys/arch/i386/compile/MARVIN i386

System: NetBSD mac-g4.nathanw.com 3.99.3 NetBSD 3.99.3 (G4) #85: Tue May  3 15:59:03 EDT 2005 nathanw@marvin-the-martian.nathanw.com:/nbsd/src/sys/arch/macppc/compile/G4 macppc

Architecture: powerpc
Machine: macppc
>Description:

Configure a kernel with FAST_IPSEC.

Set up ESP to another machine with a simple /etc/ipsec.conf (fed to setkey -c):

add 10.1.0.15 10.1.0.5 esp 1236 -E rijndael-cbc 0x79d06d135aadaba411ee0663fbcf969bc0137e91b0677e39; 
add 10.1.0.5 10.1.0.15 esp 1237 -E rijndael-cbc 0x92a933b4621cd5599d53834bdf3012d22cf460f8589f7166; 
spdadd 10.1.0.15 10.1.0.5 any -P out ipsec esp/transport//use;

Ping the other machine with a packet with more than 1940 data bytes:

ping -c 1 -s 1941
(1940 doesn't cause a problem; 1941, 1942, and 3000 all cause problems)


panic: kernel diagnostic assertion "remain < (256 - ((size_t)(unsigned long)(&(((struct _mbuf_dummy *)0)->M_dat.M_databuf))))" failed: file "../../../../netipsec/ipsec_mbuf.c", line 245
Stopped in pid 15661.1 (ping) at        netbsd:cpu_Debugger+0x18:       lwz     r
11, r1, 0x0
db> t
0xd56bba00: at panic+0x19c
0xd56bba90: at __assert+0x3c
0xd56bbac0: at m_makespace+0x404
0xd56bbb00: at esp_output+0x29c
0xd56bbb60: at ipsec4_process_packet+0x1d8
0xd56bbbe0: at ip_output+0x550
0xd56bbce0: at rip_output+0x15c
0xd56bbd70: at rip_usrreq+0x270
0xd56bbdb0: at sosend+0x2d8
0xd56bbe10: at sendit+0x170
0xd56bbe80: at sys_sendto+0x64
0xd56bbed0: at syscall_plain+0xe0
0xd56bbf40: user SC trap #133 by 0xeff37b24: srr1=0xf032
            r1=0xffffd890 cr=0x44000024 xer=0 ctr=0xeff37b1c
db> 

The network interface is:
wm0 at pci1 dev 4 function 0: Intel i82545GM 1000BASE-T Ethernet, rev. 4
wm0: interrupting at irq 25
wm0: Ethernet address 00:04:23:b2:30:90
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 5
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3f80<TSO4>
        enabled=0
        address: 00:04:23:b2:30:90
        media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause)
        status: active
        inet 10.1.0.15 netmask 0xffffff00 broadcast 10.1.0.255

The problem doesn't occur with FAST_IPSEC removed.

With des-cbc instead of rijndael-cbc, the first problematic size
option is -s 1949.

The problem does not seem to appear on the recieve side; pinging with
1950-byte packets from the other machine works fine. This doesn't make
a lot of sense to me; perhaps it has to do with how the mbufs are
structured on an incoming packet vs. a packet constructed by the ping
command?

The problem was reproducable on an i386 system, also with a wm
interface. A crash dump was generated; GDB produced the following
trace on the dump:

(gdb) target kcore netbsd.0.core
panic: kernel %sassertion "%s" failed: file "%s", line %d
#0  0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
#1  0xc04e3000 in ?? ()
#2  0xc028afb1 in cpu_reboot (howto=256, bootstr=0x0)
    at ../../../../arch/i386/i386/machdep.c:752
#3  0xc02214b0 in panic (
    fmt=0xc03d1280 "kernel %sassertion \"%s\" failed: file \"%s\", line %d")
    at ../../../../kern/subr_prf.c:242
#4  0xc0334ddc in __assert (t=0xc036daf9 "diagnostic ", 
    f=0xc0397420 "../../../../netipsec/ipsec_mbuf.c", l=245, 
    e=0xc0397460 "remain < (256 - ((size_t)(unsigned long)(&(((struct _mbuf_dummy *)0)->M_dat.M_databuf))))") at ../../../../../../lib/libkern/__assert.c:45
#5  0xc013cfef in m_makespace (m0=0xc150db00, skip=20, hlen=24, off=0xcc3abc0c)
    at x86/intr.h:160
#6  0xc0140809 in esp_output (m=0xc150db00, isr=0xc17e8280, mp=0x0, skip=20, 
    protoff=9) at ../../../../netipsec/xform_esp.c:742
#7  0xc013de23 in ipsec4_process_packet (m=0xc150db00, isr=0xc17e8280, 
    flags=38, tunalready=0) at ../../../../netipsec/ipsec_output.c:486
#8  0xc0115ed8 in ip_output (m0=0xc150db00)
    at ../../../../netinet/ip_output.c:765
#9  0xc0117e90 in rip_output (m=0xc150db00) at ../../../../netinet/raw_ip.c:374
#10 0xc0118380 in rip_usrreq (so=0xc15076c0, req=9, m=0xc150db00, 
    nam=0xc1518100, control=0x0, p=0xcc3644d4)
    at ../../../../netinet/raw_ip.c:631
#11 0xc02383e3 in sosend (so=0xc15076c0, addr=0xc1518100, uio=0xcc3abea4, 
    top=0xc150db00, control=0x0, flags=0, p=0xcc3644d4)
    at ../../../../kern/uipc_socket.c:886
#12 0xc023c4f5 in sendit (p=0xcc3644d4, s=3, mp=0xcc3abf14, flags=0, 
    retsize=0xcc3abf5c) at ../../../../kern/uipc_syscalls.c:538
#13 0xc023c308 in sys_sendto (l=0xcc367190, v=0xcc3abf64, retval=0xcc3abf5c)
    at ../../../../kern/uipc_syscalls.c:420
#14 0xc02931db in syscall_plain (frame=0xcc3abfa8)
    at ../../../../arch/i386/i386/syscall.c:161
(gdb) f 5
#5  0xc013cfef in m_makespace (m0=0xc150db00, skip=20, hlen=24, off=0xcc3abc0c)
    at x86/intr.h:160
160                     Xspllower(nlevel);
(gdb) p/x *m0
$10 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xcb03e838, 
    mh_owner = 0x0, mh_len = 0x7b1, mh_flags = 0x9000003, 
    mh_paddr = 0x3ed25b00, mh_type = 0x1}, M_dat = {MH = {MH_pkthdr = {
        rcvif = 0x0, tags = {slh_first = 0x0}, len = 0x7b1, csum_flags = 0x0, 
        csum_data = 0x0, segsz = 0x79f0b8c0}, MH_dat = {MH_ext = {
          ext_buf = 0xcb03e800, ext_free = 0x0, ext_arg = 0xc03f5b60, 
          ext_size = 0x800, ext_type = 0xbbd604b8, ext_nextref = 0xc150db00, 
          ext_prevref = 0xc150db00, ext_un = {extun_paddr = 0x3ecbc800, 
            extun_pgs = {0x3ecbc800, 0x5ee88aa0, 0x66792ac4, 0xb17b1c0f, 
              0x67174405, 0x40cf25d9, 0x735eaa4f, 0xcd16cff4, 0x7d2605f6, 
              0x3510fc1d, 0x9fc8df02, 0x3d155d19, 0xedeb128c, 0xed154e05, 
              0x78a0cad8, 0x6d06d05e, 0x4828d5fa}}, ext_ofile = 0xc0376d65, 
          ext_nfile = 0x0, ext_oline = 0x1b2, ext_nline = 0x0}, MH_databuf = {
	.....

More information from the crash dump can be provided on request.

>How-To-Repeat:
See above.

>Fix:

Unknown. Fix the "XXX code doesn't handle clusters XXX" in ipsec_mbuf.c?