A flaw was discovered [1] in how systemtap handled DWARF expressions when unwinding the stack. This could result in an invalid pointer read, leading to reading kernel memory, or a kernel 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, an admin would have to enable unprivileged mode (giving users membership in the 'stapusr' group and configuring the local machine with 'signer,all-users' stap-server trust). If an admin has enabled unprivileged mode, a user with such access could use this to crash the local machine. A workaround is to disable unprivileged mode. This will be corrected in a forthcoming upstream release of systemtap, and is currently fixed in git [2]. It is believed that this flaw was introduced via git commit 16d59279f [3], so would affect systemtap >=1.4. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13714 [2] http://sourceware.org/git/?p=systemtap.git;a=commit;h=64b0cff3b [3] http://sourceware.org/git/?p=systemtap.git;a=commit;h=16d59279f
CVE-2012-0875 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-0875): SystemTap 1.7, 1.6.7, and probably other versions, when unprivileged mode is enabled, allows local users to obtain sensitive information from kernel memory or cause a denial of service (kernel panic and crash) via vectors related to crafted DWARF data, which triggers a read of an invalid pointer.
This is fixed upstream since release 2.0 (which contains commit [2])
All affected ebuilds removed from the tree.
Maintainer(s), Thank you for cleanup! Security please Vote on GLSA
GLSA vote: yes
GLSA Vote: Yes Created a New GLSA request.
This issue was resolved and addressed in GLSA 201406-04 at http://security.gentoo.org/glsa/glsa-201406-04.xml by GLSA coordinator Chris Reffett (creffett).