This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 56186 - pstree fails to show process tree
pstree fails to show process tree
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: psmisc (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-13 13:16 EST by Randolph Bentson
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-20 11:41:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Randolph Bentson 2001-11-13 13:16:17 EST
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 11:40:47 EST
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 12:01:17 EST
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 13:46:43 EST
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 14:45:47 EST
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.