Subject: kern/8190: endian bug in ipfilter triggers frag panic
To: None <gnats-bugs@gnats.netbsd.org>
From: None <proff@suburbia.net>
List: netbsd-bugs
Date: 08/11/1999 07:36:27
>Number:         8190
>Category:       kern
>Synopsis:       endian bug in ipfilter triggers frag panic
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 11 07:35:01 1999
>Last-Modified:
>Originator:     Julian Assange
>Organization:
	
>Release:        <NetBSD-current source date> NetBSD-current 1.4J
>Environment:
	
System: NetBSD xxx.lanl.gov 1.4J NetBSD 1.4J (XXX) #7: Wed Aug 11 21:54:39 EST 1999 root@xxx.lanl.gov:/orb/x/sys/arch/i386/compile/XXX i386

>Description:
	

#2  0xf013a301 in panic (fmt=0xf0146208 "m_copym")
    at ../../../../kern/subr_prf.c:217
#3  0xf0146264 in m_copym (m=0x0, off0=548, len=528, wait=1)
    at ../../../../kern/uipc_mbuf.c:415
#4  0xf0180378 in ip_output (m0=0xf04f660c)
    at ../../../../netinet/ip_output.c:624
#5  0xf01862ef in tcp_output (tp=0xf052240c)
    at ../../../../netinet/tcp_output.c:1048
#6  0xf018805a in tcp_usrreq (so=0xf052bec4, req=4, m=0x0, nam=0xf0478188,
    control=0x0, p=0xfaf213c8) at ../../../../netinet/tcp_usrreq.c:386
#7  0xf014791a in soconnect (so=0xf052bec4, nam=0xf0478188)
    at ../../../../kern/uipc_socket.c:299
#8  0xf014a92f in sys_connect (p=0xfaf213c8, v=0xfaf3ff88, retval=0xfaf3ff80)
    at ../../../../kern/uipc_syscalls.c:293
#9  0xf01f3266 in syscall (frame={tf_es = 31, tf_ds = 31, tf_edi = 933651259,
      tf_esi = 1, tf_ebp = -272672792, tf_ebx = 245648, tf_edx = 1074053912,
      tf_ecx = 0, tf_eax = 98, tf_trapno = 3, tf_err = 2, tf_eip = 1074341947,
      tf_cs = 23, tf_eflags = 658, tf_esp = -272676916, tf_ss = 31,
      tf_vm86_es = 0, tf_vm86_ds = 0, tf_vm86_fs = 0, tf_vm86_gs = 0})
    at ../../../../arch/i386/i386/trap.c:753

This critical path in ip_output is missed:

       if ((u_int16_t)ip->ip_len <= mtu) {
                HTONS(ip->ip_len);
                HTONS(ip->ip_off);
                ip->ip_sum = 0;
                ip->ip_sum = in_cksum(m, hlen);
                error = (*ifp->if_output)(ifp, m, sintosa(dst), ro->ro_rt);
                goto done;
        }

As ipfilter has left ip->ip_len in a network byte-order state, when it should
be in host byte order.

As a consequence the packet undergoes fragmentation, despite the fact that
it is smaller than mtu. The code path in ip_output can not deal with this
situation and ends up passing off a NULL mbuf to m_copym with the
inevitable results.

The machine concerned uses state rules in the following form:

pass out quick proto tcp from any to any flags S/SA keep state keep frags

The ipfilter code path is tickled in some-manner by outbound mail delivery,
however most outbound emails do not trigger it. Usually a mid-sized queue
run to a system that has been down will do the trick. Perhaps resend processing
or hash collisions are involved?

>How-To-Repeat:
	
See above
>Fix:
	
>Audit-Trail:
>Unformatted:
no
critical endian bug in ipfilter triggers ip frag panic
critical
high
sw-bug