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 (panic_on_oops), 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.
Created attachment 497383 [details] patch to correct the flaw This patch corrects both divide by zero issues.
Also note that the doctored binary must already be running on the system, and that a privileged user would then have to be tricked into inspecting it in a particular way, in order to take advantage of this flaw.
Adjusted the title a little to make clear this is a specific case of div-by-zero. Other user input is already checked for such issues.
Great, thank you for that correction. The description of the flaw itself is fine?
It's probably worth mentioning that the bug exists in processing the malevolent DWARF code in two script language constructs: stack unwinding (backtracing) and $context variable access, for that user-space binary.
I'm trying to understand this issue. It seems there are two potential divide by zero conditions. We can group them in one CVE ID, as long as both affect the same versions of systemtap. Does the second testcase not work in RHEL5 becuase the issue isn't there, or some other reason? Also, for deciding on severity, could a regular user who is able to run sysytemtap write a script capable of crashing the machine? If they can, this is probably a low severity issue since it would then require a malicious user to trick someone into inspecting a binary in a specific way (which is unlikely). However, if non root systemtap users cannot crash a machine, but this lets them, it's slightly more severe (but still only moderate severity since you shouldn't give systemtap access to untrusted users).
Mark, the privileges question was not about what an already-root-equivalent person can do. root or stapdev can already crash the machine deliberately. The problem arises from root|stapdev being fooled into operating a particular way upon a corrupted binary, OR from a stapusr ("unprivileged") user doing so.
OK, here is where things currently stand. Due to unprivileged mode, we will rate this flaw as moderate. Without unprivileged mode enabled, this flaw doesn't cross any trust boundary. If an admin has enabled unprivileged mode though, a normal user could use this to crash the target machine. We will also want to split this to be two CVE ids. The two issues are stack unwinding (backtracing) and $context variable access. Let's use CVE-2011-1769 for the $context variable access. This affects versions of systemtap as shipped in Red Hat Enterprise Linux 5 and 6. The stack unwinding flaw only affects systemtap versions 1.4 and above. It is CVE-2011-1781.
Fixed upstream: http://sourceware.org/git/?p=systemtap.git;a=commit;h=fa2e3415185a28542d419a641ecd6cddd52e3cd9
Public now via upstream commit mentioned in the previous comment.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0842 https://rhn.redhat.com/errata/RHSA-2011-0842.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0841 https://rhn.redhat.com/errata/RHSA-2011-0841.html