CVE-2013-2094: Linux Kernel Privilege Escalation Vulnerability

CVE-2013-2094 is a privilege-escalation vulnerability in the Linux kernel. It stems from incomplete validation of a user-space configuration value related to performance events, which can produce an out-of-bounds memory access. Successful exploitation lets a local attacker gain elevated privileges on the host, which is why IT and security teams treat kernel flaws of this class as high priority even when remote code execution is not involved.

Because the kernel runs with full system privileges, any local privilege-escalation path can turn a low-privilege foothold into complete host compromise. Confirm exact impact, fixed versions, and deployment notes against the vendor advisory for your distribution.

How it works

The weakness is classified as CWE-189. According to the public summary, the Linux kernel fails to check all 64 bits of the attr.config value supplied from user space. That incomplete check leads to an out-of-bounds access of the perf_swevent_enabled array inside the sw_perf_event_destroy() routine. An attacker who can open or destroy a software performance event can therefore trigger memory corruption that is usable for privilege escalation.

In practical terms, a local process crafts a specially formed performance-event configuration, exercises the destroy path, and obtains higher privileges. No remote vector is described; the attacker already needs the ability to run code on the target system. Exact exploit mechanics and any required capabilities must be verified against the vendor advisory rather than assumed from the high-level description.

Am I affected? How to find it in your systems

The vulnerability affects the Linux kernel. Typical locations include bare-metal servers, virtual machines, containers that share the host kernel, and any appliance or embedded device running a Linux kernel that includes the performance-event subsystem.

• Inventory kernels with commands such as uname -r, cat /proc/version, or your configuration-management tool’s package query for the kernel package.
• Compare the installed kernel version and any back-ported patches against the fixed versions listed in your distribution’s security advisory for CVE-2013-2094.
• Confirm whether the perf subsystem is enabled (CONFIG_PERF_EVENTS) and whether unprivileged users can create performance events (kernel.perf_event_paranoid sysctl).
• Look for anomalous local privilege changes, unexpected root shells, or crashes involving perf-related symbols in dmesg, journalctl, or audit logs; these may indicate attempted exploitation, though they are not definitive.

If the kernel is supplied by a third-party vendor or appliance, obtain the corresponding advisory rather than relying solely on upstream version numbers.

How to remediate

Apply the vendor-supplied kernel update that addresses CVE-2013-2094. CISA’s required action is simply to apply updates per vendor instructions. After installation, reboot into the new kernel and verify the running version.

• Use your distribution’s package manager or enterprise patching system to deploy the fixed kernel package.
• For custom or long-term-support kernels, merge the upstream fix or the vendor back-port and rebuild.
• After patching, re-check the sysctl kernel.perf_event_paranoid and consider setting it to a restrictive value if unprivileged perf access is not required.
• Retest any monitoring or profiling tools that rely on the performance-event interface to ensure they still function under the hardened configuration.

If you can't patch immediately

Until the kernel can be updated, reduce the attack surface with compensating controls.

• Raise kernel.perf_event_paranoid to the most restrictive setting that still meets operational needs, limiting unprivileged creation of performance events.
• Segment hosts so that untrusted or low-privilege users cannot log in or execute code on critical systems.
• Apply host-based intrusion-prevention or SELinux/AppArmor policies that constrain the ability of unprivileged processes to open performance-event file descriptors.
• Monitor for privilege-escalation indicators (unexpected setuid binaries, new root processes, kernel oopses referencing perf) and alert on them promptly.
• If a virtual-patching or host firewall product can block the relevant system calls, enable that rule set after validating it does not break legitimate tooling.

These measures lower risk but do not eliminate the vulnerability; schedule the official kernel update as soon as possible.

If your data may have been exposed

Actively exploited privilege-escalation vulnerabilities frequently serve as the final step that turns an initial foothold into a full breach. If you have evidence of exploitation or if the host stores sensitive data, treat the system as potentially compromised: isolate it, collect forensic artifacts, rotate credentials that may have been accessible, and review access logs for lateral movement. You can also run a free exposure scan of your email addresses against known breach data sets to determine whether related accounts appear in public dumps.