ghsa-7qvj-8m4h-6v7j
Vulnerability from github
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": [],
"aliases": [
"CVE-2025-37936"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T16:15:30Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: KVM: Mask PEBS_ENABLE loaded for guest with vCPU\u0027s value.\n\nWhen generating the MSR_IA32_PEBS_ENABLE value that will be loaded on\nVM-Entry to a KVM guest, mask the value with the vCPU\u0027s desired PEBS_ENABLE\nvalue. Consulting only the host kernel\u0027s host vs. guest masks results in\nrunning the guest with PEBS enabled even when the guest doesn\u0027t want to use\nPEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply\nlooking at exclude_host can\u0027t differentiate between events created by host\nuserspace, and events created by KVM on behalf of the guest.\n\nRunning the guest with PEBS unexpectedly enabled typically manifests as\ncrashes due to a near-infinite stream of #PFs. E.g. if the guest hasn\u0027t\nwritten MSR_IA32_DS_AREA, the CPU will hit page faults on address \u00270\u0027 when\ntrying to record PEBS events.\n\nThe issue is most easily reproduced by running `perf kvm top` from before\ncommit 7b100989b4f6 (\"perf evlist: Remove __evlist__add_default\") (after\nwhich, `perf kvm top` effectively stopped using PEBS).\tThe userspace side\nof perf creates a guest-only PEBS event, which intel_guest_get_msrs()\nmisconstrues a guest-*owned* PEBS event.\n\nArguably, this is a userspace bug, as enabling PEBS on guest-only events\nsimply cannot work, and userspace can kill VMs in many other ways (there\nis no danger to the host). However, even if this is considered to be bad\nuserspace behavior, there\u0027s zero downside to perf/KVM restricting PEBS to\nguest-owned events.\n\nNote, commit 854250329c02 (\"KVM: x86/pmu: Disable guest PEBS temporarily\nin two rare situations\") fixed the case where host userspace is profiling\nKVM *and* userspace, but missed the case where userspace is profiling only\nKVM.",
"id": "GHSA-7qvj-8m4h-6v7j",
"modified": "2025-05-20T18:30:55Z",
"published": "2025-05-20T18:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37936"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/160153cf9e4aa875ad086cc094ce34aac8e13d63"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34b6fa11431aef71045ae5a00d90a7d630597eda"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/44ee0afc9d1e7a7c1932698de01362ed80cfc4b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/58f6217e5d0132a9f14e401e62796916aa055c1b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86aa62895fc2fb7ab09d7ca40fae8ad09841f66b"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.