4.198. systemtap

Security Fix

CVE-2011-2503

A race condition flaw was found in the way the staprun utility performed module loading. A local user who is a member of the stapusr group could use this flaw to modify a signed module while it is being loaded, allowing them to escalate their privileges.

BZ#718678

When running the "with server" portion of the SystemTap buildok test suite, the server needs an authorized certificate for signing the code the compiler server built. In some cases, a client running the test suite never obtained the authorized certificate. Consequently, additional failures were reported by the test suite compared to the self-hosted buildok test runs. This bug has been fixed and now, results for the "with server" portion of test suite and the self-hosted test suite match.

BZ#709190

The systemtap data structure to track address accesses requires a locking mechanism to prevent data corruption. Previously, spinlocks were used but they caused kernel panics if excessive contention for reading the data structure occurred. With this update, the locking mechanism has been changed to rwlock, which allows concurrent reading of the data structure, thus fixing this bug.

BZ#711976

For some error conditions (such as "out of memory"), the debugfs directory associated with a systemtap script remained in the system even after the script exited. Consequently, other scripts run afterwards were unable to create their own debugfs directory until the system had been rebooted. With this update, the runtime transport code has been updated to remove debugfs directories every time a systemtap script exits.

BZ#706185

Previously, tracepoint names for softirq probe points (used in older kernels) and for the irq.stp tapset (used in newer kernels) did not match. Consequently, the softirq.* probe points were not found on kernels in Red Hat Enterprise Linux 5. Now, the irq.stp tapset has been updated to allow systemtap to find older softirq probe points in older kernels.

BZ#757118

In some cases, the operands in the newest version of user-space markers could not be parsed, causing some tests to fail. With this update, SystemTap parsing of marker arguments has been fixed to handle the operands for the newest version of user-space markers and the tests now pass as expected.

BZ#757723

The memory-write_shared_copy.stp test uses the memory.stp tapset's vm.write_shared_copy probe. In earlier versions of systemtap, this probe was a dummy, letting the test case falsely pass. In later versions, it became a real probe, but due to incomplete debug information generated by the gcc compiler, it cannot be fully resolved on a Red Hat Enterprise Linux 5 kernel. Consequently, the test case fails. This appeared as a regression, because the earlier pass of the test was in fact false. With this update, this test case has been designated as a "KFAIL" (known failure) and is no longer considered a regression.