Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

EGI CSIRT:Alerts/kernel-2013-05-14

From EGIWiki
Revision as of 15:23, 15 May 2013 by Tdussa (talk | contribs)
Jump to navigation Jump to search
** WHITE information - Unlimited distribution allowed                       **
** see for distribution restrictions **


Title:       Linux kernel perf_event vulnerability (CVE-2013-2094) [EGI-ADV-20130514]
Date:        2013-05-14
Updated:     2013-05-15


Update Summary

 + 2013-05-14: Initial revision.
 + 2013-05-15: Made mitigation drawbacks more explicit.
 + 2013-05-15: Revised systemtap mitigation to support v1.7
 + 2013-05-15: Added a more robust systemtap mitigation, updated recommendation


A recently-discovered vulnerability in the Linux kernel allows a local user
to escalate their privilege level and gain root access.  Working exploit code
is publicly available.


The performance measurement subsystem in the Linux kernel incorrectly casts a
64-bit integer into a 32-bit integer which is subsequently used for array
dereferencing.  Providing carefully chosen integers as input allows arbitrary
code to be executed.

The erroneous code has been introduced in kernel version 2.6.37 (commit
b0a873ebbf87bf38bf70b5e39a7cadc96099fa13 on 2010-09-09) and is fixed in kernel
version 3.8.9 (commit 8176cced706b5e5d15887584150764894e94e02f on 2013-04-15).
Additionally, the vulnerability was backported to 2.6.32 kernels by Red Hat.

Working exploit code is publicly available.  This code will not work on all
vulnerable distributions; however, it appears to work on RHEL 6 and derived

Risk Category

This issue has been assessed as CRITICAL risk by the EGI CSIRT as a working
exploit is publicly available.

Affected Software

 + Linux kernels 2.6.36-3.8.8 through 3.8.9.
 + Linux kernels 2.6.32 with Red Hat backports.


There are currently three known mitigations for this issue:

1. A general remedy that will not break the kernel performance
   measurement subsystem can be achieved with systemtap.  This
   mitigation may be somewhat difficult to use because of its

   Install the systemtap package and its dependencies, most
   notably the kernel-devel package, and create a file
   /root/mitigation.stp containing the following (without the
   BEGIN/END marker lines):
#include <linux/perf_event.h>

function sanitize_config:long (event:long) %{
        struct perf_event *event;

        event = (struct perf_event *) STAP_ARG_event;
        event = (struct perf_event *) THIS->event;
        event->attr.config &= INT_MAX;

probe kernel.function("perf_swevent_init@kernel/events/core.c").call {
---END FILE---

   Then, run the command
     stap -g /root/mitigation.stp

   This fix is not persistent across reboots.

2. This mitigation is also systemtap-based.  However, unlike the
   previous mitigation, this fix prevents kernel performance
   monitoring altogether.  It is also somewhat more robust in
   terms of deployment.

   Install the systemtap package and its dependencies, most
   notably the kernel-devel package, download
   and compile this file into a .ko file with this command:
     stap -g -p4 -m perf_event_blocker perf_event_blocker.stp

   Run the fix with the command
     staprun ./perf_event_blocker.ko

   The .ko file may be distributed and used on all machines that run
   a kernel that is identical to the one on the host used to compile
   the .ko file.

   This fix is also not persistent across reboots.

3. A much easier mitigation that will only(!) prevent the published
   exploit code from working correctly can be performed by disabling
   user-level kernel profiling:
     sysctl kernel.perf_event_paranoid=2

   This fix is not persistent across reboots.  To make it persistent,
   add the line
   to /etc/sysctl.conf.

Component Installation information

For many distributions, patched kernel packages are available.  Refer to your
distro's information channels.


It is recommended that sites implement one of the mitigations described above,
preferably either one of the systemtap fixes, and upgrade their kernels as soon
as possible as they become available for their respective distributions.


 + Mitre:
 + OSS-Sec:
 + Debian:
 + Red Hat:
 + Ubuntu:
 + LIU SystemTap mitigation: