From owner-freebsd-bugs  Mon Jun  2 00:00:08 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA03056
          for bugs-outgoing; Mon, 2 Jun 1997 00:00:08 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA03016;
          Mon, 2 Jun 1997 00:00:03 -0700 (PDT)
Date: Mon, 2 Jun 1997 00:00:03 -0700 (PDT)
Message-Id: <199706020700.AAA03016@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: kern/3749: Kernel panic with kernel-PPP and natd-1.4
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/3749; it has been noted by GNATS.

From: j@uriah.heep.sax.de (J Wunsch)
To: mph@pobox.com (Matthew Hunt)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/3749: Kernel panic with kernel-PPP and natd-1.4
Date: Mon, 2 Jun 1997 08:46:58 +0200

 As Matthew Hunt wrote:
 
 > #5  0xf014c91e in pppfcs (fcs=62816, cp=0xf044f149 "\026&t", len=-5)
                                                                ^^^^^^
 That's the culprit.  pppfcs counts the address down until the length
 is 0.  With a negative length, this will always crash.
 
 >     at ../../net/ppp_tty.c:577
 > #6  0xf014caaf in pppstart (tp=0xf01edee8) at ../../net/ppp_tty.c:674
 
 pppstart() obtains this length directly from an mbuf.  I've got too
 few clues about the upper layers to investigate why this packet made
 it there.
 
 As a stop-gap measure, you could modify the counter in pppfcs() to
 
 	while (len-- > 0)
 
 Perhaps this lets you find more about the misbehaviour (since it will
 only yield an invalid packet then, but hopefully not crash).
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)