Bug 29319 - uu/getty segfaults on missing gettydefs speed entry
uu/getty segfaults on missing gettydefs speed entry
Product: Red Hat Linux
Classification: Retired
Component: getty_ps (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2001-02-24 21:47 EST by jstern
Modified: 2014-03-16 22:19 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-27 11:44:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jstern 2001-02-24 21:47:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686)

the getty and uugetty executables both segfault with no debugging data if
they are given a 'speed' label command line option which does not exist in
the /etc/gettydefs.

Reproducible: Always
Steps to Reproduce:
1. make sure no "DT115200" entry exists in your /etc/gettydefs

2. either run getty from the /etc/inittab with an entry like this:

 S1:2345:respawn:/sbin/getty ttyS1 DT115200 vt520

or from the command line like this:

 % /sbin/getty ttyS1 DT115200 vt520

Actual Results:  when run either from inittab or from command line, the
system log (/var/log/messages) will show an entry like this:

<date> <hostname> getty[<pid>]: Segmentation fault

when run from the inittab of course, it will produce several entries like
the above (not just one, as with command line execution), and then INIT
will shut it down for 5 minutes. then it will respawn and you'll see the
same errors again. INIT's respawning notices will appear on the system
console on the stderr.

Expected Results:  when program cannot find supplied speed entry in the
/etc/gettydefs, it should 

a) check whether the supplied speed entry exists in the /etc/gettydefs,

b) log an error to the system log saying something like:

<date> <hostname> getty[<pid>] cannot find speed label: "DT115200" does not
exist in /etc/gettydefs

c) exit gracefully.

(without the above, i spent a whole day debugging this problem).

1) also, in packing the rpm (getty_ps-2.0.7j-12.i386.rpm), you have omitted
the author's original source site from your rpm info (rpm -q -i getty_ps).
also, you have omitted the author's .lsm file from your distribution. this
means it was impossible for me to locate the source (for additional
info/hints/etc) through your .rpm itself. it took quite a while for me to
locate it (and i didn't want to download and unpack your .src.rpm, and many
people might not even know about these)

2) i am also sending the the author, Kris Gleason, a more detailed email
message describing the problem and some additional info, including
performance when run from his supplied pre-compiled binary, etc.

3) problem originally surfaced when we moved a vt520 terminal from one
linux box to the other and didn't *also* copy the special /etc/gettydefs
entry (DT115200) we use for that terminal.
Comment 1 Bill Nottingham 2001-02-26 13:21:26 EST
getty_ps is passing some rather silly flags to the compiler.
Will be fixed in the next getty_ps build, but it may be a real compiler bug.

Jakub: it segfaults when trying to syslog the error (table.c:272)
when compiled with -fomit-frame-pointer.
Comment 2 Jakub Jelinek 2001-02-27 05:52:02 EST
Smells like a gcc bug, but it looks like it is present in all of egcs 1.1.2,
gcc-2.95.2, gcc-2.96-RH and gcc-3.1 CVS. Will try to reduce it even more than
I have done already and try to fix it.
Comment 3 Jakub Jelinek 2001-02-27 11:44:28 EST
This is not gcc bug, table.c is doing horrible things like writing before
start of a buffer or not terminating a buffer after strncpy:
--- getty_ps/table.c.jj Tue Feb 27 12:45:37 2001
+++ getty_ps/table.c    Tue Feb 27 18:40:00 2001
@@ -78,9 +78,11 @@ int mode;
                /* get the first (label) field
-               (void) strncpy(buf_id, buf, MAXID);
-               if ((p = strtok(buf_id, "# \t")) != (char *) NULL)
-                       *(--p) = '\0';
+               p = buf + strspn (buf, "# \t");
+               (void) strncpy(buf_id, p, MAXID);
+               buf_id[MAXID] = '\0';
+               if ((p = strpbrk (buf_id, "# \t")) != NULL)
+                 *p = '\0';
                /* if Check is set, parse all entries;
                 * otherwise, parse only a matching entry
(I've sent this in email as well, because this one will have whitespace
Comment 4 Bill Nottingham 2001-04-03 00:26:44 EDT
This was fixed; the fixed package should have been in rawhide.

Note You need to log in before you can comment on or make changes to this bug.