From proff@iq.org  Wed Oct  1 06:24:03 1997
Received: from iq.org (proff@profane.iq.org [203.4.184.222])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA12716
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 1 Oct 1997 06:23:55 -0700 (PDT)
Received: (qmail 11645 invoked by uid 110); 30 Sep 1997 21:03:54 -0000
Message-Id: <19970930210354.11644.qmail@iq.org>
Date: 30 Sep 1997 21:03:54 -0000
From: proff@iq.org
Reply-To: proff@iq.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: <Synopsis of the problem (one line)> ftpd panics kernel on (ppp only?) links
X-Send-Pr-Version: 3.2

>Number:         4671
>Category:       kern
>Synopsis:       ftpd panics kernel on (ppp only?) links
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct  1 06:30:01 PDT 1997
>Closed-Date:    Mon Nov 3 08:07:17 PST 1997
>Last-Modified:  Mon Nov  3 08:08:10 PST 1997
>Originator:     Julian Assange
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
>Environment:

	

>Description:

	

ftpd uses the following code:

#ifdef TCP_NOPUSH
        /*
         * Turn off push flag to keep sender TCP from sending short packets
         * at the boundaries of each write().  Should probably do a SO_SNDBUF
         * to set the send buffer size as well, but that may not be desirable
         * in heavy-load situations.
         */
        on = 1;
        if (setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, (char *)&on, sizeof on) < 0)
                syslog(LOG_WARNING, "setsockopt (TCP_NOPUSH): %m");
#endif
#ifdef SO_SNDBUF
        on = 65536;
        if (setsockopt(s, SOL_SOCKET, SO_SNDBUF, (char *)&on, sizeof on) < 0)
                syslog(LOG_WARNING, "setsockopt (SO_SNDBUF): %m");
#endif

There is a fatal interaction/overflow between these in the tcp stack somewhere.

My *guess* is that there is a bad boundary check/u_short wrap etc somehow interacting
with mtu guessed tcp mss.

Obviously any user can panic kernel also, by emulating the above.

>How-To-Repeat:

	

This code does NOT panic if one/some of the following are true (unsure which)
	
	(1) the client is on a freebsd box (possibly due to rfc1323 + rfc1644 tcp
	    extension interaction)

	(2) the client packets come in via enet and not ppp (doesn't
	    seem likely, but can't rule it out)

	(3) MTU is large (1500 vs 552)

The kernel panics during a transfer.

Additionaly, the ppp driver was the in-kernel ppp driver, not tun.

>Fix:
	
	

	Work around for ftpd is to merely undef TCP_NOPUSH and
	SO_SNDBUF. It is possible that turning off net.inet.tcp.rfc1323
        or rfc1644 might also have an effect - untested.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->freebsd-bugs 
Responsible-Changed-By: max 
Responsible-Changed-When: Thu Oct 2 15:48:47 PDT 1997 
Responsible-Changed-Why:  
Misfiled PR. 

From: Bill Fenner <fenner@parc.xerox.com>
To: freebsd-gnats-submit@freebsd.org, proff@iq.org
Cc:  Subject: Re: kern/4671: ftpd panics kernel on (ppp only?) links
Date: Sun, 2 Nov 1997 22:16:14 PST

 Do you have a stack trace or a crash dump?  I have been unable to
 get a 2.2.2 machine to panic by FTP'ing files to it or from it over
 a ppp link, although since the PR doesn't really say how you
 caused the panics I can't say I tried what you tried.

From: proff@iq.org
To: fenner@parc.xerox.com (Bill Fenner)
Cc: freebsd-gnats-submit@freebsd.org, proff@iq.org
Subject: Re: kern/4671: ftpd panics kernel on (ppp only?) links
Date: Mon, 3 Nov 1997 17:23:44 +1100 (EST)

 > From fenner@parc.xerox.com Mon Nov 03 06:17:01 1997
 > Delivered-To: proff@iq.org
 > Sender: fenner@parc.xerox.com
 > Message-ID: <345D6C2E.41C67EA6@parc.xerox.com>
 > Date: Sun, 2 Nov 1997 22:16:14 PST
 > From: Bill Fenner <fenner@parc.xerox.com>
 > X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386)
 > To: freebsd-gnats-submit@freebsd.org, proff@iq.org
 > Subject: Re: kern/4671: ftpd panics kernel on (ppp only?) links
 
 > Do you have a stack trace or a crash dump?  I have been unable to
 > get a 2.2.2 machine to panic by FTP'ing files to it or from it over
 > a ppp link, although since the PR doesn't really say how you
 > caused the panics I can't say I tried what you tried.
 > 
 
 I just waited for someone to ftp a file.
 
 Note that after further testing, I came to the conclusion that it
 has nothing to do with setsockopt(). The real cause of the problem
 was that my anon ftp area was a union mount.
 
 <looks foolish>
 
 There wasn't any problem with wufpd though.
 
 -J
State-Changed-From-To: open->closed 
State-Changed-By: fenner 
State-Changed-When: Mon Nov 3 08:07:17 PST 1997 
State-Changed-Why:  
The problem was that the anonymous ftp area was a union mount. 
>Unformatted:
