Bug 56186 - pstree fails to show process tree
Summary: pstree fails to show process tree
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: psmisc
Version: 7.2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-11-13 18:16 UTC by Randolph Bentson
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-11-20 16:41:08 UTC
Embargoed:


Attachments (Terms of Use)

Description Randolph Bentson 2001-11-13 18:16:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.10 i686; Nav)

Description of problem:
pstree from psmisc-20.1-2 fails to show process tree;
pstree from psmisc-19-2 (from earlier RH dist) works just fine.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. % pstree

It looks like line 525 of pstree.c should read
 if ( sscanf(readbuf, "%*d (%[^)]", comm) == 1)
instead of
 if ( sscanf(readbuf, "%*d (%15c", comm) == 1)

2.
3.
	

Actual Results:  %

Expected Results:  init-+-afpd
     |-atalkd
     |-atd
     |-crond
...
%

Additional info:

It looks like line 525 of pstree.c should read
 if ( sscanf(readbuf, "%*d (%[^)]", comm) == 1)
instead of
 if ( sscanf(readbuf, "%*d (%15c", comm) == 1)

Comment 1 Bernhard Rosenkraenzer 2001-11-20 16:40:47 UTC
Works here without any problems. Can you reproduce this on any other machine?
By any chance, are you using a nonstandard kernel that modifies the layout of 
/proc files?


Comment 2 Bernhard Rosenkraenzer 2001-11-20 17:01:17 UTC
Since your patch can't hurt (even though the original version works on 
standard setups), I've added it to 20.2-1.



Comment 3 Randolph Bentson 2001-11-20 18:46:43 UTC
At first I suspected kernel version problems, so I rebooted with the kernel
distributed in RH72.  The problem persisted.  Your note caused me to check
further.  I installed RH72 on a system this past Saturday and it doesn't exhibit
the probem.  The problem appears on a system which was upgraded from RH71 to
RH72.  This morning I decided to check library issues. The "installed" system
shows:
$ ldd /usr/bin/pstree
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x40020000)
        libc.so.6 => /lib/libc.so.6 (0x40061000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
The "upgraded" system shows:
$ ldd /usr/bin/pstree
        /lib/libsafe.so.1.3 => /lib/libsafe.so.1.3 (0x40017000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x40037000)
        libc.so.6 => /lib/libc.so.6 (0x40078000)
        libdl.so.2 => /lib/libdl.so.2 (0x401ad000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000

It appears that libsafe <http://www.bell-labs.com/org/11356/libsafe.html>
doesn't properly determine that "comm" is big enough, and thus it suspects
possible buffer overflow.  My patch just better hides what's happening.

Comment 4 Randolph Bentson 2001-11-20 19:45:47 UTC
Further examination shows that the problem is not that "comm" is too small, but
rather the source string is too short for "%15c".  Without going into libsafe
code, I suspect that it not only protects from "stack smashing", but also from
potential "stack sniffing".  A naive implementation of the original "%15c" would
allow the code to read beyond the end of the source string.  The proposed format
'%[^)]' will never read beyond the end of the source string, which keeps libsafe
happy.  (It appears that glibc doesn't "sniff" in this way, so the authors of
libsafe may be overly cautious.)


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