>Number:         13329
>Category:       kern
>Synopsis:       ipf's ftp proxy may crash
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 28 01:07:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Martin Husemann
>Release:        1.5.1_Beta2
>Organization:
	
>Environment:
	
System: NetBSD emmas.up-vision.de 1.5.1_BETA2 NetBSD 1.5.1_BETA2 (EMMAS) #0: Wed May 23 11:16:22 CEST 2001 martin@wilhelminas:/usr/src/sys-i4b/arch/i386/compile/EMMAS i386


>Description:

Our NAT router crashed today. Gdb shows:

panic: m_copydata
#0  0xc0276a91 in mbtypes ()
(gdb) bt
#0  0xc0276a91 in mbtypes ()
#1  0x704c000 in ?? ()
#2  0xc0206fc3 in cpu_reboot (howto=256, bootstr=0x0)
    at ../../../../arch/i386/i386/machdep.c:1174
#3  0xc01372d7 in panic () at ../../../../kern/subr_prf.c:240
#4  0xc0142fe6 in m_copydata (m=0xc064c600, off=120, len=11, cp=0xc068a06c "")
    at ../../../../kern/uipc_mbuf.c:583
#5  0xc018ca2f in ippr_ftp_process (fin=0xc9e6dbd8, ip=0xc970b810, 
    nat=0xc06df380, ftp=0xc068a000, rv=0)
    at ../../../../netinet/ip_ftp_pxy.c:647
#6  0xc018cbd2 in ippr_ftp_out (fin=0xc9e6dbd8, ip=0xc970b810, aps=0xc06d8e00, 
    nat=0xc06df380) at ../../../../netinet/ip_ftp_pxy.c:726
#7  0xc018d85e in appr_check (ip=0xc970b810, fin=0xc9e6dbd8, nat=0xc06df380)
    at ../../../../netinet/ip_proxy.c:261
#8  0xc0189e94 in ip_natout (ip=0xc970b810, fin=0xc9e6dbd8)
    at ../../../../netinet/ip_nat.c:2011
#9  0xc017be89 in fr_check (ip=0xc970b810, hlen=20, ifp=0xc02eb400, out=1, 
    mp=0xc9e6dca4) at ../../../../netinet/fil.c:1013
#10 0xc018ad0b in ip_output (m0=0x1c1) at ../../../../netinet/ip_output.c:548
#11 0xc0186ae5 in ip_forward (m=0xc064c600, srcrt=0)
    at ../../../../netinet/ip_input.c:1494
#12 0xc0185940 in ip_input (m=0xc064c600) at ../../../../netinet/ip_input.c:625
#13 0xc0185590 in ipintr () at ../../../../netinet/ip_input.c:337

This is the code:

581             while (len > 0) {
582                     if (m == 0)
583                             panic("m_copydata");
584                     count = min(m->m_len - off, len);
585                     memcpy(cp, mtod(m, caddr_t) + off, count);
586                     len -= count;
587                     cp += count;

len = 3, off = 0; gdb couldn't find "count".

One level up it's calling m_copydata with off = 120 and len = 11.

The mbuf passed to m_copydata is:

{m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc970b810 "E", 
    mh_len = 128, mh_type = 1, mh_flags = 11}, M_dat = {MH = {MH_pkthdr = {
        rcvif = 0xc059002c, len = 128, aux = 0x0}, MH_dat = {MH_ext = {
          ext_buf = 0xc970b800 "οΎ", ext_free = 0, ext_arg = 0x0, 
          ext_size = 2048, ext_type = -25843520, ext_nextref = 0xc064cc00, 
          ext_prevref = 0xc064cc00}, 
        MH_databuf = ....

So using the remaining 8 bytes (128-off) here, subtracting that from 11 (len),
we have the 3 bytes remaining, but no data in the mbuf chain any more.

Since len in this case is mlen, which is calculated using mbufchainlen()-off,
I don't see what happened. Someone is modifying the mbuf chain while we
are processing it?

>How-To-Repeat:

Use ipf's ftp proxy & have bad luck?

>Fix:
n/a
>Release-Note:
>Audit-Trail:
>Unformatted: