cbcvebase.
CVE-2025-37936
published 2025-05-20

CVE-2025-37936: In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.17%
6.9th percentile
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU's value. When generating the MSR_IA32_PEBS_ENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBS_ENABLE 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 exclude_host 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 MSR_IA32_DS_AREA, 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 __evlist__add_default") (after which, `perf kvm top` effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intel_guest_get_msrs() 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.

Affected

33 ranges· showing 25
VendorProductVersion rangeFixed in
debiandebian_linux
debianlinux< linux 6.1.140-1 (bookworm)linux 6.1.140-1 (bookworm)
debianlinux-6.1< linux 6.1.140-1 (bookworm)linux 6.1.140-1 (bookworm)
linuxlinux
linuxlinux>= c59a1f106f5cd4843c097069ff1bb2ad72103a67 < 160153cf9e4aa875ad086cc094ce34aac8e13d63160153cf9e4aa875ad086cc094ce34aac8e13d63
linuxlinux>= c59a1f106f5cd4843c097069ff1bb2ad72103a67 < 34b6fa11431aef71045ae5a00d90a7d630597eda34b6fa11431aef71045ae5a00d90a7d630597eda
linuxlinux>= c59a1f106f5cd4843c097069ff1bb2ad72103a67 < 44ee0afc9d1e7a7c1932698de01362ed80cfc4b544ee0afc9d1e7a7c1932698de01362ed80cfc4b5
linuxlinux>= c59a1f106f5cd4843c097069ff1bb2ad72103a67 < 86aa62895fc2fb7ab09d7ca40fae8ad09841f66b86aa62895fc2fb7ab09d7ca40fae8ad09841f66b
linuxlinux>= c59a1f106f5cd4843c097069ff1bb2ad72103a67 < 58f6217e5d0132a9f14e401e62796916aa055c1b58f6217e5d0132a9f14e401e62796916aa055c1b
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.1.140-16.1.140-1
linuxlinux_kernel>= 0 < 6.12.29-16.12.29-1
linuxlinux_kernel>= 0 < 6.12.29-16.12.29-1
linuxlinux_kernel>= 0 < 6.8.0-100.1006.8.0-100.100
linuxlinux_kernel>= 0 < 6.14.0-24.246.14.0-24.24
linuxlinux_kernel>= 6.0 < 6.1.1386.1.138
linuxlinux_kernel>= 6.13 < 6.14.66.14.6
linuxlinux_kernel>= 6.2 < 6.6.906.6.90
linuxlinux_kernel>= 6.7 < 6.12.286.12.28
msrcazl3_kernel_6.6.85.1-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.92.2-1_on_azure_linux_3.0
ubuntulinux-aws

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_msrc7.0HIGH
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.