CVE-2026-31528

What it actually does

This is a local Linux kernel memory-corruption flaw in the perf subsystem. Under specific perf event grouping and inheritance conditions, the kernel can use the wrong PMU context when rolling back a failed group scheduling operation, leading to an out-of-bounds memory access in kernel space. Because the flaw is reachable through local perf event operations, a low-privileged local user or process may be able to trigger a kernel crash and, depending on exploitability on a given architecture and kernel build, potentially achieve kernel-level code execution or privilege escalation. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user, compromised application, or containerized workload with access to perf functionality to crash the host kernel or potentially gain elevated privileges on the system. This is most operationally significant for shared Linux servers, CI/CD runners, container hosts, high-performance computing environments, and multi-user platforms where untrusted or semi-trusted users can run code. The issue is not currently listed in CISA KEV, has no known mature public exploit in the supplied data, and has a low stable EPSS score, but Linux kernel prevalence means exposure can be broad wherever vulnerable kernels remain deployed.

How an attack unfolds

An attacker first needs local code execution on a vulnerable Linux system. They then interact with the perf_event_open interface to create a crafted set of perf events involving grouped events, inheritance across process contexts, and a software event group leader that causes PMU context handling to diverge from the expected hardware PMU context. When group scheduling fails and the kernel attempts to roll back the operation, the perf subsystem may call PMU transaction handling and deletion logic using the wrong PMU context. On affected x86 systems, this can lead to an out-of-bounds memory access in x86_pmu_del(). In the simplest case this results in a kernel oops or panic and denial of service. With reliable memory-layout control and kernel-specific exploitation work, the same corruption primitive may be usable for privilege escalation, although no mature exploit is indicated in the provided data.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream fix for the perf PMU context handling issue described as making inherited grouped events and __perf_event_read() use pmu_ctx->pmu for group cases. Because no exact fixed versions were supplied, use the kernel packages and advisories from the relevant Linux distribution or appliance vendor, and verify that the installed kernel changelog includes the perf fix for CVE-2026-31528 or the associated upstream patch. Where immediate patching is not possible, reduce exposure by restricting unprivileged perf access using sysctl settings such as kernel.perf_event_paranoid=3 where supported, removing CAP_PERFMON/CAP_SYS_ADMIN from untrusted processes and containers, applying seccomp profiles that deny perf_event_open for workloads that do not require it, disabling access to performance monitoring interfaces for untrusted users, and prioritizing patching for multi-user and container-host systems. A reboot is typically required for Linux kernel updates to take effect.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated by checking uname -r after reboot and comparing it with the vendor advisory or package changelog for the perf PMU context fix. Verify that no older vulnerable kernel remains selected as the default boot entry. Check perf exposure with sysctl kernel.perf_event_paranoid and confirm that untrusted users cannot successfully call perf_event_open unless there is a business need. Validate container and service hardening by confirming seccomp profiles block perf_event_open where appropriate and that untrusted workloads do not retain CAP_PERFMON or broad administrative capabilities. Do not validate by running public proof-of-concept code on production systems; use vendor-provided kernel version checks, package metadata, configuration review, and controlled non-production testing instead.

Typical attack path

1. Obtain local ability to execute code on a vulnerable Linux host, either as a low-privileged user or through a compromised workload.
2. Confirm that perf_event_open is accessible and not blocked by sysctl policy, seccomp, container runtime policy, or capability restrictions.
3. Create perf event groups with a software event leader and PMU-backed events in a way that exercises inherited perf contexts.
4. Trigger group scheduling failure and rollback paths in the kernel perf subsystem.
5. Cause the kernel to use an inconsistent PMU context during cleanup, reaching the out-of-bounds access path.
6. Use the resulting condition to crash the kernel or attempt kernel privilege escalation if a reliable exploit has been developed for the target kernel build.

How to detect it

Look for evidence of local perf abuse and kernel instability rather than remote network indicators. Useful sources include auditd syscall logs, EDR syscall telemetry, Linux kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and container runtime security logs. Investigate unprivileged or unexpected processes making perf_event_open calls, especially at high frequency or immediately before a kernel oops, panic, host reboot, or watchdog reset. Kernel stack traces referencing x86_pmu_del(), group_sched_in(), perf_event_open(), perf_event_read(), or perf inheritance/group scheduling paths are strong leads. If auditd is enabled, searches for perf_event_open by non-root users, build tools, interpreters, temporary-directory binaries, or unknown executables can help identify suspicious attempts. In containerized environments, review workload logs and runtime telemetry for containers granted CAP_PERFMON or CAP_SYS_ADMIN and correlate with host kernel faults. Because exploitation may only leave a crash artifact, preserve vmcores and kernel logs before rotation and compare crash timing against local process execution and authentication events.

• x86_pmu_del
• group_sched_in
• perf_event_open
• __perf_event_read
• kernel.perf_event_paranoid
• BUG: unable to handle kernel
• general protection fault
• kernel NULL pointer dereference
• kernel oops
• Kernel panic
• perf: interrupt took too long
• audit:.*perf_event_open
• syscall=perf_event_open
• comm="perf"
• CAP_PERFMON

What your security team should do

• Prioritize kernel updates for shared Linux servers, container hosts, virtualization hosts, CI runners, and systems where untrusted users can run local code.
• Apply the vendor kernel update and reboot systems so the fixed kernel is actually running.
• Temporarily restrict unprivileged perf access with kernel.perf_event_paranoid=3 where supported if patching must be delayed.
• Deny perf_event_open through seccomp for containers and services that do not explicitly require performance monitoring.
• Remove CAP_PERFMON, CAP_SYS_ADMIN, and other elevated capabilities from untrusted containers and workloads wherever feasible.
• Monitor kernel logs for oops, panic, or fault traces involving perf, group_sched_in, x86_pmu_del, or perf_event_open.
• Review audit or EDR telemetry for unusual perf_event_open activity by non-administrative users or unexpected application processes.
• Treat unexplained kernel crashes on vulnerable versions as potentially security-relevant and preserve logs, vmcores, and process telemetry for investigation.