GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel perf: software events run the overflow path with IRQs enabled, racing teardown of the event's BPF program

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

Impact

__perf_event_overflow() assumed IRQs were disabled on every call path, but software events can reach it with only preemption disabled. That opens a race against perf_event_exit_event() and the rest of the teardown path, which frees state the overflow handler still expects to be there - the attached BPF program among it - so the handler can run against freed kernel objects. Distinct flaw and distinct fix from the other perf issue in this batch: the problem here is the locking context of the overflow path, not ring-buffer refcounting. Exposure on a GPU node again follows profiling policy; where tenants can open software perf events with BPF programs attached, a local user has a route at a kernel use-after-free. Siemens also lists affected SIMATIC devices running its Linux subsystem, which is irrelevant to datacenter fleets but explains the extended product list on the record.

Who can reach it

Local user able to create perf software events, in practice with a BPF program attached - unprivileged where perf_event_paranoid is relaxed or CAP_PERFMON/CAP_BPF is granted to containers. No network path.

What to do

Take the stable kernel update that forces IRQs off across all __perf_event_overflow() call paths; five stable branches carry it. Rollout is drain, install kernel, reboot. Interim mitigation is the same lever as for the other perf fix: restrict perf_event_open for unprivileged users and remove CAP_PERFMON and CAP_BPF from tenant workloads.

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.