NetBSD Problem Report #8446

Received: (qmail 525 invoked from network); 19 Sep 1999 11:12:54 -0000
Message-Id: <199909191112.HAA14306@dbj.ne.mediaone.net>
Date: Sun, 19 Sep 1999 07:12:04 -0400 (EDT)
From: dbj@netbsd.org
Reply-To: dbj@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Cc: dbj@netbsd.org
Subject: if_ppp.c, no way to dump packet from compressor
X-Send-Pr-Version: 3.95

>Number:         8446
>Category:       kern
>Synopsis:       if_ppp.c, no way to dump packet from compressor
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    dbj
>State:          suspended
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 19 04:20:00 +0000 1999
>Closed-Date:    
>Last-Modified:  Wed Apr 14 04:40:41 +0000 2004
>Originator:     Darrin B. Jewell
>Release:        -current last updated around 19990917T0533Z
>Organization:
>Environment:

System: NetBSD dbj.ne.mediaone.net 1.4.1 NetBSD 1.4.1 (ROCINANTE) #0: Wed Aug 18 04:09:19 EDT 1999 dbj@dbj.ne.mediaone.net:/usr/obj.i386/ROCINANTE i386

>Description:
        There is no way for a ppp compression module to dump an
outgoing packet.  If the compression module fails to compress (due to
resource depletion, for example), the original uncompressed packet
will be sent out the wire.  This creates a security problem when
attempting to use the compress/decompress hooks to add an encryption
module to ppp.

>How-To-Repeat:

>Fix:

This patch will dump the outgoing packet if the compression function
returns a length less than zero.

Please comment.  If i receive no objections after a post to tech-net,
I will commit.  Also, would this change need to be reviewed/submitted
to upstream ppp maintainers?

Darrin

Index: if_ppp.c
===================================================================
RCS file: /cvsroot/syssrc/sys/net/if_ppp.c,v
retrieving revision 1.55
diff -u -r1.55 if_ppp.c
--- if_ppp.c	1999/07/30 10:35:38	1.55
+++ if_ppp.c	1999/09/19 10:56:48
@@ -977,6 +977,7 @@
     int address, control, protocol;
     int s;

+ again:
     /*
      * Grab a packet to send: first try the fast queue, then the
      * normal queue.
@@ -1059,6 +1060,11 @@
 	    slen += mp->m_len;
 	clen = (*sc->sc_xcomp->compress)
 	    (sc->sc_xc_state, &mcomp, m, slen, sc->sc_if.if_mtu + PPP_HDRLEN);
+	if (clen < 0) {
+		m_freem(m);
+		m_freem(mcomp);
+		goto again;
+	}
 	if (mcomp != NULL) {
 	    if (sc->sc_flags & SC_CCP_UP) {
 		/* Send the compressed packet instead of the original. */


>Release-Note:
>Audit-Trail:

From: "Darrin B. Jewell" <jewell@mit.edu>
To: gnats-bugs@gnats.netbsd.org
Cc: kern-bug-people@netbsd.org
Subject: Re: kern/8446: if_ppp.c, no way to dump packet from compressor
Date: 19 Sep 1999 07:30:50 -0400

 Actually, i'm already not happy with this fix.  I'd rather put the
 packet back on the queue and wait than just dump it and get stuck
 trying to send the next one on the queue.
Responsible-Changed-From-To: kern-bug-people->dbj 
Responsible-Changed-By: perry 
Responsible-Changed-When: Tue Apr 1 08:15:59 PST 2003 
Responsible-Changed-Why:  
dbj was the submitter and was actively working on the problem. 
He should decide whether to close the PR, or to fix the stated problem 
in some manner. 
State-Changed-From-To: open->suspended 
State-Changed-By: dbj 
State-Changed-When: Wed Apr 14 04:36:38 UTC 2004 
State-Changed-Why:  
no plans to remedy the problem, someone working encryption as a compression 
module may want to revisit in in the future, but for now its not a bug. 
>Unformatted:

Home	PR Database Search