Red Hat Bugzilla – Bug 56186
pstree fails to show process tree
Last modified: 2008-05-01 11:38:01 EDT
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)
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?
Since your patch can't hurt (even though the original version works on standard setups), I've added it to 20.2-1.
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.
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.)