CVE-2022-49562
Medium
Elevated severity or exploit probability.
CVSS base
7.8
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS — probability of exploitation (30 days)
0.3%
19.1th percentile
CISA KEV
Not listed
Weakness / dates
—
Published 2025-02-26 · modified 2026-08-04
CVSS breakdown
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
| Attack Vector | L | Local |
| Attack Complexity | L | Low |
| Privileges Required | L | Low |
| User Interaction | N | None |
| Scope | U | Unchanged |
| Confidentiality | H | High |
| Integrity | H | High |
| Availability | H | High |
Timeline
- 2025-02-26 — Published (NVD)
- 2026-08-04 — Last modified (NVD)
Description
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing "random" pfns for pretty much any other VM_PFNMAP case.