The insertmodule function in runtime/staprun/staprunfuncs.c in the systemtap runtime tool (staprun) in SystemTap before 1.6 does not properly validate a module when loading it, which allows local users to gain privileges via a race condition between the signature validation and the module initialization.

Multiple denial of service flaws were found in the SystemTap instrumentation system, when the --unprivileged mode was activated:

a, Kernel stack overflow allows local attackers to cause denial of service or execute arbitrary code via long number of parameters, provided to the print call.

b, Kernel stack frame overflow allows local attackers to cause denial of service via specially-crafted user-provided DWARF information.

c, Absent check(s) for the upper bound of the size of the unwind table and for the upper bound of the size of each of the CIE/CFI records, could allow an attacker to cause a denial of service (infinite loop).

References: ----------- http://sources.redhat.com/bugzilla/showbug.cgi?id=10750 http://gcc.gnu.org/bugzilla/showbug.cgi?id=41633

Issue severity note: -------------------- The --unprivileged mode needs to be activated by the privileged user prior the unprivileged user could exploit these flaws.

SystemTap 1.0 in the default configuration is not shipped with the --unprivileged mode activated, this is NOT vulnerable to these flaws.

Information about vulnerable versions: -------------------------------------- These issues do NOT affect the versions of SystemTap instrumentation system, as shipped with Red Hat Enterprise Linux 4 and 5.

These issues affect the versions of SystemTap instrumentation system, as shipped with Fedora releases of 10 and 11. See also above severity note.

A flaw was discovered in systemtap's handling of DWARF expressions where it did not guard against two cases of divide by zero. This can result in a kernel div-by-zero message and possible busywait during stap module shutdown. A div-by-zero could cause the kernel to panic and if the kernel reboot on panic flag was set (paniconoops), it would cause the system to reboot.

In order to trigger this flaw, it would require a user with staprun or stapdev group membership (or root privileges) to run a particular stap script operation on a hand-corrupted elf program.