From owner-cvs-usrsbin Sat Jun 13 17:57:13 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00236 for cvs-usrsbin-outgoing; Sat, 13 Jun 1998 17:57:13 -0700 (PDT) (envelope-from owner-cvs-usrsbin) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00108; Sat, 13 Jun 1998 17:56:50 -0700 (PDT) (envelope-from brian@FreeBSD.org) From: Brian Somers Received: (from brian@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA07157; Sat, 13 Jun 1998 17:56:15 -0700 (PDT) Date: Sat, 13 Jun 1998 17:56:15 -0700 (PDT) Message-Id: <199806140056.RAA07157@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG Subject: cvs commit: src/usr.sbin/ppp slcompress.c slcompress.h vjcomp.c Sender: owner-cvs-usrsbin@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk brian 1998/06/13 17:56:15 PDT Modified files: usr.sbin/ppp slcompress.c slcompress.h vjcomp.c Log: o Pass our negotiated number of VJ slots into sl_uncompress_tcp() and drop packets with slot numbers that are out of range. o Drop packets that want to use a slot that still has an IP header length of 0 (ie, the requested slot number is bogus again). Without this code, if the other side mis-behaves (and sends us garbage slot numbers), we happily ``adjust'' a memset(..., '\0', ...) TCP/IP header and promptly cr*p all over the stack before returning.... quickly followed by a SIGBUS. Dodgy ISP used by, and help locating the problem from: jmz Problem also seen by: Mourad de Riche There's still a link lockup after this happens, but my bets are on the other side (who has already started sending rubbish) being to blame. Revision Changes Path 1.17 +8 -5 src/usr.sbin/ppp/slcompress.c 1.12 +2 -2 src/usr.sbin/ppp/slcompress.h 1.18 +5 -3 src/usr.sbin/ppp/vjcomp.c