CVE-2026-64556

What it actually does

This is a local Linux kernel perf subsystem race/state-corruption vulnerability. A low-privileged local user can create perf event groups where the group leader is marked for removal on exec while sibling events remain active. When exec removes the leader without fully detaching group relationships, later close/schedule-in paths can operate on stale group state and attempt to link an already-linked active list entry, corrupting kernel PMU context lists. Depending on kernel configuration and memory-layout conditions, this can cause a kernel crash, denial of service, or potentially be shaped into local privilege escalation because the bug occurs in kernel memory management/list handling.

Why it matters to the business

Successful exploitation could allow a user or compromised low-privilege process on a Linux system to crash the host or potentially gain elevated privileges, affecting workload availability and host isolation. This is most relevant for multi-user Linux systems, shared build hosts, developer workstations, container hosts, CI runners, HPC environments, and any service where untrusted or semi-trusted users can execute local code. The vulnerability is not known to be in CISA KEV, is not reported as ransomware-used, and currently has very low EPSS, so remediation should be prioritized based on exposure to local users rather than internet-facing risk.

How an attack unfolds

An attacker first needs the ability to run local code on an affected Linux system and to access the perf_event_open interface. They create a perf event group with a leader configured for remove-on-exec behavior and one or more sibling events that survive exec. By triggering exec and then closing or otherwise manipulating the removed leader, the attacker causes the kernel to process inconsistent perf event group state. On a vulnerable kernel, subsequent scheduling of the perf events can corrupt PMU active-list structures. In the simplest outcome, this produces a kernel warning, oops, or panic; with additional exploitation work, the same class of kernel list corruption may be used to target privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for perf/core remove_on_exec group detachment. Because no product-specific fixed versions were provided, use vendor advisories for the exact patched package version for each distribution, appliance, or kernel stream in use. Where immediate patching is not possible, reduce exposure by restricting unprivileged perf access: set kernel.perf_event_paranoid to a restrictive value, remove CAP_PERFMON/CAP_SYS_ADMIN from untrusted workloads, avoid granting perf_event_open access inside containers, and limit local shell access on shared hosts. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the perf/core fix. Validate with uname -a, package-manager kernel version checks, and vendor security advisory mapping for this CVE. Check runtime mitigations with sysctl kernel.perf_event_paranoid and review whether untrusted users or containers have CAP_PERFMON, CAP_SYS_ADMIN, or perf_event_open access. On systems using live patching, confirm the relevant perf/core patch is applied and active. If DEBUG_LIST or kernel debugging is enabled, verify that reproduction no longer triggers list_add double-add warnings in merge_sched_in; otherwise, use vendor-provided regression tests or kernel selftests for perf events where available.

Typical attack path

1. Obtain local code execution as an unprivileged or low-privileged user on an affected Linux host.
2. Confirm that perf events are accessible to the user, such as through permissive kernel perf_event_paranoid settings or granted capabilities.
3. Create a perf event group with a leader that will be removed on exec while sibling events remain active.
4. Trigger exec so the leader is removed through the vulnerable remove-on-exec path without fully detaching group relationships.
5. Close or otherwise cause cleanup of the stale leader state, allowing surviving sibling events to be promoted from inconsistent group state.
6. Force a later schedule-in of the affected events, triggering PMU active-list corruption.
7. Use the resulting kernel corruption to crash the system or attempt further exploitation for privilege escalation.

How to detect it

Post-exploitation detection is difficult because the vulnerability is a local kernel memory-corruption issue and may leave only crash or kernel-warning artifacts. Review kernel logs from journald, dmesg, syslog, kmsg, crash dumps, and centralized logging for perf/core warnings, list corruption, double-add messages, kernel oopses, BUG/WARN splats, or unexpected panics around merge_sched_in and perf event cleanup. If auditd or EDR captures syscalls, look for unusual perf_event_open usage by non-administrative users, especially followed by execve and close activity and then a kernel crash or reboot. On container hosts, correlate suspicious perf_event_open activity with containers granted elevated capabilities such as CAP_PERFMON or CAP_SYS_ADMIN. Because no public exploit maturity or named threat actor activity is reported, focus on local anomaly detection and crash forensics rather than network indicators.

• list_add double-add
• merge_sched_in
• perf_event_remove_on_exec
• perf_event_exit_event
• perf/core
• DEBUG_LIST
• kernel BUG at lib/list_debug.c
• WARNING: CPU:
• Oops:
• general protection fault
• Kernel panic
• perf_event_open

What your security team should do

• Inventory Linux systems where untrusted users, CI jobs, containers, or shared workloads can execute local code.
• Prioritize patching multi-user systems, container hosts, CI runners, developer workstations, and high-value Linux servers before single-purpose systems with tightly controlled local access.
• Update to a vendor kernel containing the perf/core remove_on_exec group-detachment fix and reboot into the patched kernel.
• Apply temporary hardening by setting kernel.perf_event_paranoid to a restrictive value and removing unnecessary CAP_PERFMON/CAP_SYS_ADMIN grants from users and containers.
• Monitor kernel logs for perf-related list corruption, oops, WARN, BUG, panic, or unexpected reboots until patching is complete.
• Review EDR, auditd, or syscall telemetry for unusual perf_event_open activity by non-administrative users where available.
• Treat any crash with matching perf/core list-corruption messages as potentially security-relevant and preserve kernel logs, crash dumps, and process accounting data.