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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.