Do it explicitly instead of the implicit "longjmp() cannot cause 0 to be
returned. If longjmp() is invoked with a second argument of 0, 1 will be
returned instead."
This is one of the worst issues that we found: if the strlen() of one of
the cmdline arguments is greater than INT_MAX (it is possible), then the
"int bytes" could wrap around completely, back to a very large positive
int, and the next strncat() would be called with a huge number of
destination bytes (a stack-based buffer overflow).
Fortunately, every distribution that we checked compiles its procps
utilities with FORTIFY, and the fortified strncat() detects and aborts
the buffer overflow before it occurs.
This patch also fixes a secondary issue: the old "--bytes;" meant that
cmdline[sizeof (cmdline) - 2] was never written to if the while loop was
never entered; in the example below, "ff" is the uninitialized byte:
((exec -ca `python3 -c 'print("A" * 131000)'` /usr/bin/cat < /dev/zero) | sleep 60) &
pgrep -a -P "$!" 2>/dev/null | hexdump -C
00000000 31 32 34 36 30 20 41 41 41 41 41 41 41 41 41 41 |12460 AAAAAAAAAA|
00000010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
*
00001000 41 41 41 41 ff 0a 31 32 34 36 32 20 73 6c 65 65 |AAAA..12462 slee|
00001010 70 20 36 30 0a |p 60.|
Otherwise (for example), if the (undocumented) opt_echo is set, but not
opt_long, and not opt_longlong, and not opt_pattern, there is a call to
xstrdup(cmdoutput) but cmdoutput was never initialized:
sleep 60 & echo "$!" > pidfile
env -i LD_DEBUG=`perl -e 'print "A" x 131000'` pkill -e -c -F pidfile | xxd
...
000001c0: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
000001d0: 4141 4141 4141 4141 fcd4 e6bd e47f 206b AAAAAAAA...... k
000001e0: 696c 6c65 6420 2870 6964 2031 3230 3931 illed (pid 12091
000001f0: 290a 310a ).1.
[1]+ Terminated sleep 60
(the LD_DEBUG is just a trick to fill the initial stack with non-null
bytes, to show that there is uninitialized data from the stack in the
output; here, an address "fcd4 e6bd e47f")
Not exploitable (not under an attacker's control), but still a potential
non-security problem. Copied, fixed, and used the grow_size() macro from
pidof.c.
memset()ing task and subtask inside their loops prevents free_acquired()
(in readproc() and readtask()) from free()ing their contents (especially
cmdline and environ).
Our solution is not perfect, because we still memleak the very last
cmdline/environ, but select_procs() is called only once, so this is not
as bad as it sounds.
It would be better to leave subtask in its block and call
free_acquired() after the loop, but this function is static (not
exported).
The only other solution is to use freeproc(), but this means replacing
the stack task/subtask with xcalloc()s, thus changing a lot of code in
pgrep.c (to pointer accesses).
Hence this imperfect solution for now.
sig.c had this odd logic where on non-Hurd systems it would undefine
SIGLOST. Fine for Hurd or amd64 Linux systems. Bad for a sparc which
has SIGLOST defined *and* is not Hurd.
Just check its defined, its much simpler.
If pgrep is run with a non-program name match and there are
no matches, it segfaults.
The testsuite thinks zero bytes sent, and zero bytes sent
because the program crashed is the same :/
References:
commit 1aacf4af7fhttps://bugs.debian.org/894917
Signed-off-by: Craig Small <csmall@enc.com.au>
Update NEWS with the version
Add library API change into NEWS
Update c:r:a for library to 7:0:1
This means the current and age are incremented, so old programs can
use new library but not vice-versa as they won't have the numa*
functions.
pidof will miss scripts that are run a certain way due to how
they appear in procfs. This is just a note to say it might miss
them.
References:
procps-ng/procps#17
Hurd doesn't have HOST_NAME_MAX, neither does Solaris.
An early fix just checked for this value and used 64 instead.
This change uses sysconf which is the correct method, possibly until
this compiles on some mis-behaving OS which doesn't have this value.
References:
commit e564ddcb01procps-ng/procps#54
By default pgrep/pkill should not kill processes in a namespace it is not
part of. If this is allowed, it allows callers to break namespaces they did
not expect to affect, requiring rewrite of all callers to fix.
So by default, we should work in the current namespace. If --ns 0 is
specified, they we look at all namespaces, and if any other pid is specified
we continue to look in only that namespace.
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
With a little luck, this should be the final tweak for
our support of extra wide characters. Currently, those
characters don't always display the '+' indicator when
they've been truncated. Now, it should always be seen.
[ plus it's done a tad more efficiently via snprintf ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit had one minor bug in it because the fields need
to be alphabetical and times comes after timeout.
Added NEWS item for this feature
Added another testsuite check for new flags in case they
disappear or go strange one day.
References:
commit 8a94ed6111
I frequency use pidof command with strace system call tracer.
strace can trace MULTIPLE processes specified with "-p $PID"
arguments like:
strace -p 1 -p 1030 -p 3043
Sometimes I want to do as following
strace -p $(pidof httpd)
However, above command line doesn't work because -p option
is needed for specifying a pid. pidof uses a whitespace as
a separator. For passing the output to strace, the separator
should be replaced with ' -p '.
This maybe not a special to my use case.
This commit introduces -S option that allows a user to specify a
separator the one wants.
$ ./pidof bash
./pidof bash
24624 18790 12786 11898 11546 10766 7654 5095
$ ./pidof -S ',' bash
./pidof -S ',' bash
24624,18790,12786,11898,11546,10766,7654,5095
$ ./pidof -S '-p ' bash
./pidof -S '-p ' bash
24624-p 18790-p 12786-p 11898-p 11546-p 10766-p 7654-p 5095
$ ./pidof -S ' -p ' bash
./pidof -S ' -p ' bash
24624 -p 18790 -p 12786 -p 11898 -p 11546 -p 10766 -p 7654 -p 5095
$ strace -p $(./pidof -S ' -p ' bash)
strace -p $(./pidof -S ' -p ' bash)
strace: Process 24624 attached
strace: Process 18790 attached
strace: Process 12786 attached
...
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
The procio functions that were in the library have been
moved into sysctl. sysctl is not linked to libprocps in
newlib and none of the other procps binaries would need
to read/write large data to the procfs.
References:
be6b048a41
thereby use one allocated buffer for I/O which now might
be increased by the stdio function getline(3) on the
file if required.
Signed-off-by: Werner Fink <werner@suse.de>
