GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel perf/core: remove_on_exec leaves stale group state, corrupting the PMU active list

CVSS 7.8CVE-2026-64556Kernel, userspace & hypervisorcurated

Impact

When perf_event_remove_on_exec() removes a group leader, siblings without remove_on_exec can stay active while attached to the removed leader's sibling list, no longer represented by a valid leader on the PMU context active lists. A later close of the leader uses DETACH_GROUP and can promote those still-active siblings from stale state, so the next schedule-in re-adds an already-linked entry and corrupts the PMU context active list - caught as a list_add double-add with DEBUG_LIST. Linked-list corruption in core scheduling code is a credible local escalation primitive, and GPU fleets commonly expose perf to tenants for profiling (DCGM, Nsight, perf-based observability sidecars).

Who can reach it

Local user able to call perf_event_open with remove_on_exec, which depends on perf_event_paranoid and any seccomp policy in front of it. No authentication beyond a shell or container on the node.

What to do

Apply the stable fix that detaches group relationships during remove_on_exec and reboot the node. Where profiling is not needed, raising kernel.perf_event_paranoid to 3 or blocking perf_event_open in the container seccomp profile removes tenant reach in the meantime.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.