HowToFixMe
● High · CVSS 8.4 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2013-2094: Linux Kernel perf_swevent_init Privilege Escalation

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 8.4 - High (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Actively exploited?Yes, listed in CISA KEV (added 2022-09-15); public exploit semtex.c / Exploit-DB 33589
ProductLinux kernel (perf event subsystem, kernel/events/core.c)
AffectedLinux kernel before 3.8.9 (perf_event_open path, 2.6.37 onward)
Fixed inLinux kernel 3.8.9 (upstream commit 8176cced706b); distro backports below
TypeLocal privilege escalation via incorrect integer data type (signed/unsigned confusion)

Exploitation status

CVE-2013-2094 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Linux Kernel Privilege Escalation Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: a public exploit on Exploit-DB has been published. Assume opportunistic scanning and weaponization; prioritize accordingly.

Authoritative references:

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-09-15, federal due date 2022-10-06.

What is CVE-2013-2094?

CVE-2013-2094 is a local privilege-escalation flaw in the Linux kernel, specifically in the performance counters (perf) subsystem. The perf_swevent_init function in kernel/events/core.c, in every kernel before 3.8.9, uses an incorrect integer data type when it validates the software event ID passed to the perf_event_open system call. An unprivileged local user supplies a crafted event ID and gains root.

The technical root cause is a signed versus unsigned mismatch. The event ID arrives in a u64 from userspace, but the bounds check that guards the perf_swevent_enabled array reads it through an int (later corrected to u64 in the fix). A large value with the high bit set reads back as a negative number, slips past the if (event_id >= PERF_COUNT_SW_MAX) check, and is then used as an array index. That turns into an out-of-bounds increment and decrement of kernel memory at an attacker-influenced offset. The public exploits weaponise that controlled write to overwrite a function pointer or credentials structure and drop into a root shell.

Two details make this CVE notable. It needs no remote access, no special capability, and no user interaction beyond an ordinary shell, which is why the CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H for a base score of 8.4. And the bug existed since kernel 2.6.37 (early 2011), so it shipped in long-lived enterprise distributions: RHEL 6, CentOS 6, Ubuntu 12.04/12.10, openSUSE, and SLES all needed backported fixes.

Why this CVE matters

CISA added CVE-2013-2094 to the Known Exploited Vulnerabilities catalog on 2022-09-15 as a Linux kernel privilege-escalation vulnerability, which only happens after active exploitation is observed. The original exploit, semtex.c by Brad Spengler / the “sd” release, and Exploit-DB entry 33589 are both public and reliable, and were used heavily to break out of shared-hosting and CI accounts in 2013. On any multi-tenant box, a single untrusted local account on an unpatched kernel means full root compromise. If a vulnerable kernel ran where untrusted users had shell access, treat that window as a likely breach and investigate rather than assume.

Check whether you are affected

This is a kernel bug, so the only thing that matters is the running kernel version, not any package or application. Check it directly:

# Running kernel version - the only number that matters here
uname -r

# Distro package version, for cross-referencing the advisory
dpkg -l 'linux-image-*' 2>/dev/null | grep '^ii'     # Debian / Ubuntu
rpm -q kernel                                         # RHEL / CentOS / Rocky / SUSE

If uname -r reports an upstream kernel older than 3.8.9, or a distribution kernel older than the patched build named in your vendor advisory (for example earlier than 2.6.32-358.6.1.el6 on RHEL 6 per RHSA-2013:0830), the host is vulnerable until you update and reboot.

How to fix CVE-2013-2094

The fix is upstream Linux kernel 3.8.9 (commit 8176cced706b5e5d15887584150764894e94e02f, which changes the offending int to u64 so the bounds check can no longer be bypassed). In practice you do not build upstream, you install your distribution's backported kernel package and reboot. Pick the block that matches your distro.

Ubuntu / Debian

Ubuntu shipped the fix in USN-1825-1 through USN-1838-1 across the 12.04/12.10 kernel flavours. Install the latest kernel metapackage and reboot:

sudo apt-get update
sudo apt-get install --only-upgrade linux-image-generic linux-generic
sudo reboot
# after reboot, confirm the new kernel is running
uname -r

RHEL / CentOS / Rocky / AlmaLinux

Red Hat shipped RHSA-2013:0830 (kernel 2.6.32-358.6.1.el6 for RHEL 6); CentOS mirrored it as CESA-2013:0830. Update the kernel package and reboot into it:

sudo yum update kernel          # RHEL 6 / CentOS 6 era
# or, on dnf-based systems:
sudo dnf update kernel
sudo reboot
uname -r

openSUSE / SUSE Linux Enterprise

SUSE shipped SUSE-SU-2013:0819 and the openSUSE-SU-2013:0847/0925/0951/1042 updates. Apply the kernel patch and reboot:

sudo zypper refresh
sudo zypper patch          # or: sudo zypper update kernel-default
sudo reboot
uname -r

A kernel update never takes effect until the machine reboots into the new image. If you cannot reboot immediately, apply the mitigation below first and schedule the reboot as an emergency change.

If you can't reboot immediately

There is no config flag that removes this bug, but you can block the common exploit path. The public exploits reach the vulnerable code through perf_event_open, so restricting unprivileged access to perf cuts off the standard route:

# Block unprivileged perf_event_open access until you reboot into 3.8.9+
sudo sysctl -w kernel.perf_event_paranoid=2
# make it persist across reboots
echo 'kernel.perf_event_paranoid = 2' | sudo tee /etc/sysctl.d/99-cve-2013-2094.conf

This is a stopgap, not a cure: the buggy int conversion is still in the running kernel, and a process that already holds CAP_SYS_ADMIN or a path that reaches the code another way is not blocked. On multi-tenant hosts, also remove shell access for untrusted users until the patched kernel is live.

Verify the fix

After the reboot, confirm the running kernel is the patched build, not just that a new package is installed on disk:

uname -r                                  # must be 3.8.9+ upstream, or the patched distro build
rpm -q kernel                             # RHEL/SUSE: should list the fixed package version
dpkg -l 'linux-image-*' | grep '^ii'      # Debian/Ubuntu: confirm the new image is installed

Then run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2013-2094. If untrusted users had local access while the host ran a vulnerable kernel, review logs for unexpected privilege changes, new accounts, and out-of-band cron or systemd entries, and rotate any credentials a local root could have read.

Frequently asked questions

Which Linux kernel versions are affected by CVE-2013-2094?

Every Linux kernel before 3.8.9 that ships the perf event subsystem is affected. The signed/unsigned bug was introduced in 2.6.37 when PERF_COUNT_SW_MAX-based array indexing in perf_swevent_init was added, so 2.6.37 through 3.8.8 are vulnerable. The fix landed in the 3.8.9 stable release (commit 8176cced706b), with distribution backports onto older kernels such as RHEL 6's 2.6.32.

Do I need local access to exploit CVE-2013-2094, or is it remote?

It is a local privilege escalation, not a remote bug. An attacker needs an unprivileged local shell. They call perf_event_open with a crafted event ID; the out-of-bounds array write corrupts kernel memory and is turned into a root shell. The public semtex.c exploit and Exploit-DB entry 33589 do exactly this and were widely used to break out of shared hosting and CI accounts.

Can I mitigate CVE-2013-2094 without rebooting into a patched kernel?

Partially. Setting kernel.perf_event_paranoid to 2 or higher with sysctl restricts unprivileged access to perf_event_open and blocks the common exploit path until you reboot into kernel 3.8.9 or your distribution's patched build. It is a stopgap, not a fix, because the vulnerable code still runs.

How do I confirm CVE-2013-2094 is fixed after patching?

Run uname -r and confirm the running kernel is your distribution's patched build (for example RHSA-2013:0830 on RHEL 6, or USN-1825 through USN-1838 on Ubuntu) or upstream 3.8.9 or later. A kernel update only takes effect after a reboot, so verify after the system has rebooted into the new kernel.

References

This guide was assembled from the upstream Linux kernel fix commit and 3.8.9 ChangeLog, the Red Hat, Ubuntu, and SUSE advisories, the NVD record, and the CISA KEV catalog entry. Always confirm against your distribution's advisory before applying changes in production.

Additional nearby issues sensible to fix in the same maintenance window:

People also ask

Which Linux kernel versions are affected by CVE-2013-2094?

Every Linux kernel before 3.8.9 that ships the perf event subsystem. The bug was introduced in 2.6.37, so 2.6.37 through 3.8.8 are vulnerable. The fix landed in 3.8.9 (commit 8176cced706b), with backports onto older distribution kernels such as RHEL 6's 2.6.32.

Do I need local access to exploit CVE-2013-2094, or is it remote?

It is a local privilege escalation. An attacker needs an unprivileged local shell, then calls perf_event_open with a crafted event ID. The public semtex.c exploit and Exploit-DB entry 33589 turn the out-of-bounds write into a root shell.

Can I mitigate CVE-2013-2094 without rebooting into a patched kernel?

Partially. Setting kernel.perf_event_paranoid to 2 or higher restricts unprivileged perf_event_open access and blocks the common exploit path until you reboot into kernel 3.8.9 or your distribution's patched build. It is a stopgap, not a fix.