CVE-2025-37936: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value.

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: KVM: Mask PEBSENABLE loaded for guest with vCPU's value.

When generating the MSRIA32PEBSENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBSENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at excludehost can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest.

Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSRIA32DSAREA, the CPU will hit page faults on address '0' when trying to record PEBS events.

The issue is most easily reproduced by running perf kvm top from before commit 7b100989b4f6 ("perf evlist: Remove evlistadddefault") (after which, perf kvm top effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intelguestgetmsrs() misconstrues a guest-owned PEBS event.

Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events.

Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM and userspace, but missed the case where userspace is profiling only KVM.