GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel perf: wrong PMU's transaction handlers on software-leader groups cause out-of-bounds access

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

Impact

When a perf event group's leader is a software event, inheritance cloned events using event->pmu instead of pmu_ctx->pmu, undoing the move_group placement and putting inherited counters in the wrong PMU context. Rolling back a failed group_sched_in() then runs the wrong PMU's transaction callbacks, and the reported symptom is an out-of-bounds memory access in x86_pmu_del(). __perf_event_read() had the same mismatch for the group case. This is host kernel memory corruption reachable through perf_event_open() with a mixed software/hardware group, and perf is not optional equipment on a GPU fleet - profilers, continuous-profiling agents and DCGM-adjacent tooling open these events routinely, so the path is exercised by normal operations as well as by an attacker.

Who can reach it

Local user able to call perf_event_open() and build an event group with a software leader - available unprivileged wherever perf_event_paranoid is relaxed, otherwise requiring CAP_PERFMON. Not remotely reachable.

What to do

Update the host kernel to a build carrying the stable fix commits below and reboot each node. Until then, restrict perf to privileged users (raise kernel.perf_event_paranoid, do not grant CAP_PERFMON to tenant pods), which closes the unprivileged path but still leaves your own profiling agents on the fixed code's behalf.

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.