Subject: bin/12058: SEGV in dhclient (parse_encapsulated_suboptions)
To: None <gnats-bugs@gnats.netbsd.org>
From: Ben Harris <bjh21@netbsd.org>
List: netbsd-bugs
Date: 01/27/2001 14:36:18
>Number: 12058
>Category: bin
>Synopsis: SEGV in dhclient (parse_encapsulated_suboptions)
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Jan 27 14:39:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Ben Harris
>Release: 1.5
>Organization:
>Environment:
NetBSD viking 1.5 NetBSD 1.5 (VIKING) #4: Fri Jan 26 23:16:18 GMT 2001
bjh21@viking:/usr/src/sys/arch/macppc/compile/VIKING macppc
>Description:
Running dhclient on an ntl cable-modem connection causes it to die with a
SIGSEGV when it gets a response from the server. A debugging build run
under gdb revealed the problem to occur in
parse_encapsulated_suboptions(), where it does:
/* If we don't have a decoding function for it, we can't decode
it. */
if (!universe -> decode)
return 0;
At this point in the code, it turned out that "universe" had a small, but
non-zero value, apparently because it had never been initialised.
>How-To-Repeat:
Connect to the ntl cable modem service in Cambridge and try to use
dhclient. In case it's useful, the thing that dhclient read from its bpf
descriptor looked like this:
244 dhclient CALL read(0x6,0x190b000,0x2000)
244 dhclient GIO fd 6 read 364 bytes
":r\^F\^?\0\0\M^Z"\0\0\^AV\0\0\^AV\0\^V\M->\M-o\M-^\M--\0\240\M-L^<\^Y\
\0\M-P\M-:\v]T\b\0E\0\^AHO\M-o\0\0\M^?\^Q\^_x\M-,\^P\M-[\M-~>\M-}\M^D1\
\0C\0D\^A4\M-0\^V\^B\^A\^F\0q<\M-c\M-C\0\0\0\0\0\0\0\0>\M-}\M^D1\0\0\0\
\0>\M-}\M^D\M-~\0\240\M-L^<\^Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0c\M^BSc5\^A\^B6\^D>\M-}\M^@\^C3\^D\0\08@\^A\^D\M^?\M^?\
\M^?\0\^\\^D\M^?\M^?\M^?\M^?\^C\^D>\M-}\M^D\M-~\^F\b>\M-}\M-"\M-k\M-B\
\M-(\bdR\^N\^A\^D\0\^A\0\^B\^B\^F\0\^PK\M-a\M-i\M-H\M^?"
244 dhclient RET read 364/0x16c
>Fix:
This patch seems to help. Since there's a test for "universe"'s being
NULL, which is commented as being for the case where a universe wasn't
found, I've arranged to initialise "universe" to NULL.
I'm not sure this fix is correct, though, since I still get a variety of
interesting messages from dhclient that look as if it's having problems
with option parsing. It works well enough to get my system running,
though.
Index: options.c
===================================================================
RCS file: /cvsroot/basesrc/usr.sbin/dhcp/common/options.c,v
retrieving revision 1.3.2.2
diff -u -r1.3.2.2 options.c
--- options.c 2000/10/18 04:11:11 1.3.2.2
+++ options.c 2001/01/27 22:35:17
@@ -185,7 +185,7 @@
unsigned len, struct universe *eu,
struct universe *vu)
{
- struct universe *universe;
+ struct universe *universe = NULL;
int i;
char *s, *t;
>Release-Note:
>Audit-Trail:
>Unformatted: