A flaw was discovered  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
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 . It is believed that this flaw was
introduced via git commit 16d59279f , so would affect
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 )
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).