このコンテンツは選択した言語では利用できません。
4.316. systemtap
Updated systemtap packages that fix one security issue are now available for Red Hat Enterprise Linux 5 and 6.
The Red Hat Security Response Team has rated this update as having moderate security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below.
SystemTap is an instrumentation system for systems running the Linux kernel. The system allows developers to write scripts to collect data on the operation of the system.
Security Fix
- CVE-2012-0875
- An invalid pointer read flaw was found in the way SystemTap handled malformed debugging information in DWARF format. When SystemTap unprivileged mode was enabled, an unprivileged user in the stapusr group could use this flaw to crash the system or, potentially, read arbitrary kernel memory. Additionally, a privileged user (root, or a member of the stapdev group) could trigger this flaw when tricked into instrumenting a specially-crafted ELF binary, even when unprivileged mode was not enabled.
SystemTap users should upgrade to these updated packages, which contain a backported patch to correct this issue.
Updated systemtap packages that fix several bugs and adds various enhancements are now available for Red Hat Enterprise Linux 6.
SystemTap is a tracing and probing tool that allows users to study and monitor the activities of the operating system (particularly, the kernel). It provides information similar to the output of tools like netstat, ps, top, and iostat; however, SystemTap provides more filtering and analysis options.
- BZ#683483
- The systemtap package has been upgraded to upstream version 1.6, which provides a number of bug fixes and enhancements:
- SystemTap now handles kernel modules with "-" in the name such as "i2c-core" properly.
- The process().mark() function now supports the $$parms log parameter for reading probe parameters.
- The operation of the compile-server and client was improved and simplified:
- The compile server can cache the script build results.
- The compile server and client communicate exchange version info to adjust the communication protocol and use the newest version of the compile server.
- The following deprecated tools were removed: stap-client, stap-authorize-server-cert, stap-authorize-signing-cert, stap-find-or-start-server, and stap-find-servers.
- For remote execution, the "--remote USER@HOST" functionality can now be specified multiple times, and will automatically build the script for distinct kernel and architecture configurations and run it on all named machines at once.
- The staprun program allows to run multiple instances of the same script at the same time.
Bug Fixes
- BZ#711757
- When the system ran out of memory in a module, SystemTap failed to remove the module directory created by the debugfs debugger. Consequently, SystemTap was unable to load the module until after a system reboot and a kernel panic could occur. With this update, SystemTap removes the module directory properly.
- BZ#708255
- The rate of error or warning messages, sent from the probe module to user-space, caused various buffer overflows under certain circumstances. As a result, the messages could be lost and caused a kernel panic. With this update, these messages are also delivered if there is an excessive amount of warning or error messages.
- BZ#732346
- SystemTap uses the make command to search for available tracepoints ('kernel.trace("*")'). Previously, the make operation printed out a number of misleading error messages on the first tracepoint search. Because search results are cached, the error messages were produced only on the first search. With this update, the tracepoint search uses the "make -i" (ignore errors) operation, the error messages from the make operations are supressed, and no misleading output is printed when performing tracepoint searches.
- BZ#737095
- Prior to this update, starting a SystemTap server could fail. This occurred because the getlogin() function returned a NULL pointer when initializing an std::string object. With this update, the underlying code has been modified and the problem no longer occurs.
- BZ#692970
- The sdt.c tests in the testsuite were attempting to include the unavailable sdt_types.h header file, and the compilation of the systemtap-testsuite package failed. With this update, the sdt.c tests no longer need the sdt_types.h file and system-testsuite is compiled as expected.
- BZ#718151
- The unprivileged probing of user-space applications was not documented properly. This update adds information to the manual pages on unprivileged probing of user-space applications.
- BZ#691763
- On some architectures, SystemTap could not find certain functions to probe or variables to fetch in highly optimized code. As a consequence, the cxxclass.exp test script failed on PowerPC. This update adds the "-DSTAP_SDT_ARG_CONSTRAINT=nr" option to the cxxclass.exp test script. With this option the arguments are accessible to SystemTap and the test works as expected on PowerPC.
- BZ#692445
- The stap_run.exp test script incorrectly matched the end of the file and the tests using the script were reported as failed on IBM System z although the tests succeeded. With this update, the end-of-line matching has been fixed and the tests on IBM System z pass as expected.
- BZ#723536
- The stap command with the "--remote" parameter failed to properly copy the systemtap_session object on Intel x86, PowerPC and IBM System z architectures. Consequently, instrumentation failed to be built and the utility terminated with a segmentation fault. Now, the underlying code copies the systemtap_session object properly and the stap command builds instrumentation as expected.
- BZ#723541
- The stap command with the "--remote" parameter did not use the proper canonical names on Intel x86, PowerPC and IBM System z architectures. Consequently, instrumentation failed to built. With this update, the underlying session code has been modified to properly copy kernel/arch information and the stap command builds instrumentation correctly in such scenarios.
- BZ#738242
- On startup, SystemTap needs to allocate memory to individual CPUs for the data transport layer. Previously, SystemTap used the number of all potential CPUs instead of online (schedulable) CPUs to estimate the required memory. Consequently, SystemTap could incorrectly indicate that there was not enough memory available on startup and exit. With this update, the underlying code has been modified and SystemTap now uses the number of online CPUs to estimate the memory needed for data transport layer.
- BZ#685064
- When probing a user-space module, SystemTap needs the uprobe.ko kernel module. If the module does not exist, it is built. Previously, this could lead to a race condition if multiple scripts probing user-space applications attempted to built the missing uprobes.ko kernel module. The parallel builds of uprobes.ko could interfere with each other and cause the scripts to fail. With this update, the stap command caches the resulting uprobe.ko kernel module to avoid interfering with SystemTap instrumentation instances. Multiple SystemTap scripts probing user-space applications now no longer interfere with each other regardless whether a uprobe.ko kernel module exists.
- BZ#684227
- The futexes.stp example script in the SystemTap Beginners Guide did not mask out the FUTEX_PRIVATE_FLAG and FUTEX_CLOCK_REALTIME flags in newer versions of the Linux Kernel. Due to this issue, the script could not return any results. The script has been modified and returns the correct results.
- BZ#671235
- The cmdline_string() function concatenates command line arguments. However, if an empty argument ("") was used, the function did not print any arguments following the NULL argument. The handling of an empty argument was added to the definition of the cmdline_string() function and the function now prints all arguments from the command line including the arguments following the empty argument.
- BZ#607161
- There were differences between the tracepoints (kernel.trace(mm_*")) in Red Hat Enterprise Linux and upstream kernels. Due to the differences, the building and running of the mmanonpage and mmfilepage tests failed. This update adds checks which verify the tracepoints' location before running the tests and testsuite only uses the tracepoints on kernels that actually have the tracepoints.
- BZ#639344
- The syscall wrapper functions used on IBM System z converted arguments from pointers to long integers. The usymbols test assumed the arguments were pointers and the test failed. This update modifies the usymbols test in the SystemTap testsuite package and the utility handles the arguments properly.
- BZ#730884
- The kernel header files could contain mutually conflicting definitions for the tracepoints of the perf tool. However, SystemTap does not detect kernel headers with conflicting definitions. As the SystemTap translator built the module in one compile unit, the translator tool did not detect the tracepoints. The SystemTap translator now builds instrumention so that the kernel header files with the tracepoints are compiled in seperate units and the tracepoints for jbd and ext3 subsystems are now visible to SystemTap.
- BZ#733181
- The sdt.exp script ran some tests with -DEXPERIMENTAL_KPROBE_SDT, an obsolete mechanism. On some architectures the tests failed. The sdt.exp script now marks the problematic -DEXPERIMENTAL_KPROBE_SDT that fail as XFAIL. Also, the result of the tests using -DEXPERIMENTAL_KPROBE_SDT that fail are no longer included in the FAIL results.
- BZ#733182
- The sdt.exp script ran some tests with STAP_SDT_V2, an obsolete mechanism. On some architectures the tests failed because of ambiguities between numeric constants and register numbers. The sdt.exp script now marks the problematic STAP_SDT_V2 that fail as XFAIL. The result of the tests using STAP_SDT_V2 that fail are no longer included in the FAIL results.
- BZ#730167
- Probing a user-space application requires the uprobes kernel module. Previously, the "--remote" option used the path to the uprobes kernel module on the client instead of the proper path on a remote machine. If a uprobes module was not yet loaded on the remote machine, the instrumentation did not start and the following error message was printed:
ERROR: Unable to canonicalize path [...]: No such file or directory
SystemTap now loads the correct uprobe module and user-space application probing works as expected with the "--remote" option even if the uprobe kernel module is not currently loaded on remote machine. - BZ#731288
- The sdt_misc.exp test did not take into account that some code in sdt_types.c was compiled conditionally, which caused that the number of probe points available could change. As a consequence, the sdt_misc.exp test failed on 32-bit and 64-bit AMD architectures because the number of probe points available did not match the expected value. With this update, the sdt_misc.exp test now takes into account the conditionally compiled code in sdt_types.c when deciding the number of probe points and the test passes as expected.
Enhancements
- BZ#600400
- In the verbose mode, the stap-client utility now shows progress information of the communication with the server.
Users of systemtap are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.