Subject: Re: kern/30098: nmap causes kern panic in m_pulldown on sparc64
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Martin Husemann <martin@duskware.de>
List: netbsd-bugs
Date: 05/02/2005 08:16:01
The following reply was made to PR kern/30098; it has been noted by GNATS.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/30098: nmap causes kern panic in m_pulldown on sparc64
Date: Mon, 2 May 2005 10:15:45 +0200

 The panic happens in tcp_input.c line 938:
 
        /*
          * tcp_input() has been modified to use tlen to mean the TCP data
          * length throughout the function.  Other functions can use
          * m->m_pkthdr.len as the basis for calculating the TCP data length.
          * rja
          */
                 
         if (off > sizeof (struct tcphdr)) {
                 IP6_EXTHDR_GET(th, struct tcphdr *, m, toff, off);
                 if (th == NULL) {
                         tcpstat.tcps_rcvshort++;
                         return;
                 }
  
 inside the IP6_EXTHDR_GET macro.
 
 #define IP6_EXTHDR_GET(val, typ, m, off, len) \
 do {                                                                    \   
         struct mbuf *t;                                                 \
         int tmp;                                                        \
         if ((m)->m_len >= (off) + (len))                                \
                 (val) = (typ)(mtod((m), caddr_t) + (off));              \
         else {                                                          \
                 t = m_pulldown((m), (off), (len), &tmp);                \
                 if (t) {                                                \
                         if (t->m_len < tmp + (len)) {                   \
 
 after m_pulldown t->m_len is 16, tmp is 0, off is 20 and len is 20 too.
 t->m_flags is 0x402 (M_CANFASTFWD|M_PKTHDR) and the (funny) lengths
 of the mbufs in the chain are: 16, 8, 8, 8.
 
 I already tried uipc_mbuf2.c rev. 1.17, but that did not fix it.
 Anyone remember what might have fixed this post 2.0?
 
 Martin