The command line length value is not properly checked and limited to the
documented 1024 bytes, even though a MAX_CMD_LEN is already defined but
not used.
With this, an overflow of the static char mon_record[] buffer is possible
in read_cmdline(), corrupting adjacent .bss data. The data is sanitized to
printable ASCII bytes, but in theory a crash of the mon_procd daemon could
be possible.
Fix it by adding a check and truncation similar to the other restricted
fields like e.g. ruser_len or cmd_len.
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The output of /proc/<pid>/stat will show the process name in parentheses.
The parsing code in read_stat() tries to filter out the parentheses, which
will go wrong when the process name itself also contains parentheses, e.g.
in an output like this: "2421 ((sd-pam)) S 2420 2420 2420 ..."
In this case, the first closing parentheses will be taken as end marker,
and the sscanf() on the remaining string will silently fail, leaving its
values in uninitialized state and producing wrong data.
Fix this by using strrchr() instead of strchr() to find the last closing
parentheses. Also add return value checking for sscanf() and initialize the
values to 0.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes the same issue as in commit 82c8148983 ("cpuplugd: Improve
systemctl start error handling") for mon_tools (mon_procd and mon_fsstatd).
Currently "systemctl start mon_procd/fsstatd" does not report any errors
in case the startup fails.
Example (with mon_procd):
(change interval in /etc/sysconfig/mon_procd to an invalid value "abc")
# systemctl start mon_procd
The reason is that for type=simple systemd forks/execs mon_procd and if
that is successful immediately returns. There is no way to find out if the
initial startup fails.
Fix this by using type=fork and running the process in the background. In
this case systemd waits until the initial process returns.
In addition use PIDFile and ensure that the pid file is already available
when the initial process returns. To achieve this, use startup
synchronization via pipe. Without that systemd would print the following
warning:
systemd[1]: mon_procd.service: PID file /var/run/mon_procd.pid not readable
(yet?) after start: No such file or directory
With this patch, an early startup error like in the example above, is now
reported correctly in "systemctl start":
# systemctl start mon_procd
Job for mon_procd.service failed because the control process exited...
See "systemctl status mon_procd.service" and "journalctl -xe" for ...
# journalctl -xe | grep mon_procd
mon_procd[3184]: Error: Invalid interval (needs to be greater than 0)
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
