GPU VulnDB

Database/Kernel, userspace & hypervisor

perf sched: integer overflow and strcpy overflow parsing untrusted perf.data

CVSS 9.3CVE-2026-80671Kernel, userspace & hypervisorcurated

Impact

register_pid() in perf sched trusts values from a perf.data file: (pid + 1) * sizeof(struct task_desc *) can wrap on 32-bit systems so realloc returns a tiny buffer that the init loop then writes past, and strcpy() copies an untrusted comm string into a fixed 20-byte COMM_LEN buffer. Allocation failure hit a BUG_ON, and a bad realloc pattern left nr_tasks incremented over a leaked pointer. The fix caps pid at PID_MAX_LIMIT, uses strlcpy, and returns NULL instead of crashing. This is the userspace perf binary, not the kernel: it only bites an operator who runs perf sched on a profile handed to them by someone else - a tenant's uploaded trace, a support bundle, an artifact from a shared profiling pipeline. On a GPU node where profiling traces move between tenants and the performance team, that path is real but deliberate; there is no remote or unprivileged-tenant trigger.

Who can reach it

A local user who runs perf sched over a perf.data file supplied by an attacker. Code execution would be in the context of whoever runs perf, which is often root on a GPU node. No authentication bypass and no remote path.

What to do

Update the perf userspace package from your distribution once it carries the fix (five stable commits are linked); this is a package update, not a kernel change, so no reboot or drain is needed. As an operational mitigation, do not run perf sched as root on profiles from an untrusted source - analyse them as an unprivileged user or in a throwaway container.

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.