CVE-2022-49562: Safer KVM PTE Updates with __try_cmpxchg_user

The Linux kernel fix tracked as CVE-2022-49562 closes a subtle but real KVM x86 bug that could let the hypervisor path touch the wrong physical frames while updating guest page-table accessed/dirty (A/D) bits — the upstream remedy replaced a fragile PTE-mapping trick with the safer __try_cmpxchg_user() primitive. The change was small in code but significant for correctness: it prevents the kernel from mapping guest PTEs into kernel address space and avoids accidental access to arbitrary PFNs that, in practice, could cause crashes, instability, or denial-of-service against hosts running KVM.

Background / overview​

The problem addressed by CVE-2022-49562 sits at the intersection of two kernel concerns: virtualization (KVM) and the low-level mechanics of updating page-table metadata. KVM must emulate or manage guest page tables and, in some code paths, it needs to update the guest PTE A (accessed) and D (dirty) bits as the guest runs. Historically, some code paths did this by mapping the guest PTE into kernel virtual memory and performing updates there — a convenient but brittle approach when the PTE backing assumptions changed. The upstream patch replaces the mapping approach with a user-address atomic update helper, __try_cmpxchg_user(), which performs the update without pulling the PTE into kernel address space.
Two technical points are central to understanding the bug and its remedy:

• vm_pgoff vs PFN: the VM_PFNMAP path assumed vm_pgoff acts like the base PFN (page frame number) of the mapped VMA. That assumption is wrong: vm_pgoff is an offset relative to the file, not the physical pfn, and misusing it can cause the kernel to reference wrong PFNs. The mapping “hack” worked in a narrow original use-case (backing guest memory from /dev/mem) but fails in general VM_PFNMAP instances.
• Atomic user-space update: __try_cmpxchg_user() is the safer primitive introduced to attempt an atomic compare-and-exchange on a user address without mapping it into kernel space; using it avoids the logic and address-space pitfalls that caused accidental PFN dereferences. The patch therefore reduces the attack surface and race-prone code-paths.

Timeline and disclosure notes​

• The kernel patch series implementing these uaccess/CMPXCHG primitives and the KVM change was published on the kernel mailing list in early 2022 (patch posting: Feb 1, 2022). That mailing-list thread documents the technical rationale and the exact code changes.
• The CVE entry and vendor advisories surfaced publicly in 2025 (February 2025 listings across several distro advisories and tracking databases). That timing reflects how fixes and CVE assignments sometimes lag original patch submissions — a common occurrence for kernel fixes that were upstreamed earlier but only later correlated with CVE identifiers and distribution advisories. Administrators should note the difference between upstream-patch dates and when a CVE or distribution backport appears in their platform’s security tracker.

What exactly was the impact?​

At a functional level, the bug could cause the kernel to access incorrect PFNs when walking a VM_PFNMAP mapping and updating guest PTE A/D bits. Practical consequences observed and cataloged by vendor trackers include:

• Availability impact (primary): kernel oops, crashes, or instability resulting in guest or host denial-of-service. Several trackers mark the availability impact as the most relevant consequence.
• Integrity/confidentiality: vendor databases and advisories generally do not attribute confidentiality or integrity loss to this specific defect — the core concern is accidental access to wrong PFNs and resulting instability, not a remote code execution or data disclosure vector. That said, kernel instability at the hypervisor level can be operationally severe in multi-tenant setups.
• Attack model: local/host-adjacent. Exploitation would require local capability or crafted host conditions (for example, code running in a guest that exercises the vulnerable VM_PFNMAP path). This makes it a higher-cost, lower-scalability attack compared with remote unauthenticated bugs, but high-value in cloud or co-located multi-tenant scenarios.

How vendors and trackers characterized severity (and why the numbers differ)​

Different trackers and distributions published slightly different severities and scores:

• AWS/ALAS and some distro trackers list a CVSSv3 score around 5.5 (Medium) focusing on AV:L/PR:L and an emphasis on Availability impact.
• Other aggregators (e.g., some Rapid7 entries) report higher numeric severity variants depending on how they translated the underlying impact vectors; discrepancies stem from differing interpretations of scope, privileges required, and whether distributions backported fixes or marked packages as “not affected.”

A cautionary note: NVD records for this entry did not show a consistent NVD-assigned score at the time some vendor pages were updated, which is why you may see differing numbers across various trackers. Treat published CVSS values as useful triage signals, but verify specifics with your distribution’s security advisories and the upstream kernel commits if you need definitive technical reasoning.

Technical anatomy: what the patch changed (developer view)​

The upstream patch set does two things in this area:

• Introduces or reuses safe user-address atomic primitives in the x86/uaccess layer (CMPXCHG helpers) so the kernel can attempt atomic updates on addresses that logically belong to user or guest address space without mapping them into kernel linear space.
• Rewrites the KVM code that previously mapped a guest PTE into kernel virtual space and performed updates there. Instead, the code now calls __try_cmpxchg_user() (or the appropriate wrapper) to flip A/D bits in-place without creating transient kernel mappings that can be mis-indexed by vm_pgoff assumptions.

That minimal but focused change removes a brittle mapping hack and the associated VM_PFNMAP assumptions, substantially lowering the chance of unintentionally touching arbitrary PFNs. The patch was designed to be low-risk in functional behavior while addressing correctness and safety.

Who is affected — distribution and kernel scope​

Affected surface depends on which kernels and backports are in use:

• Upstream/mainline kernels that lacked the __try_cmpxchg_user() update in the KVM x86 paths are the primary upstream target of the fix; the original patches appeared in early 2022.
• Distribution kernels: Debian, Ubuntu, Red Hat, Amazon Linux and other vendors published advisories or security-tracker entries in early 2025 once the CVE mapping and backporting process completed. The practical result is that some long-term-stable kernels required distribution-specific backports or rework to pick up the safe update. Administrators must confirm whether their distribution’s kernel packages include the backport for CVE-2022-49562.
• Cloud and embedded variants: several vendors (e.g., Amazon Linux or vendor-custom kernels) may consider a release “Not Affected” or “No Fix Planned” depending on kernel configuration or support plans. Always consult your vendor’s advisory for the exact status of your platform.

Practical remediation checklist (prioritized)​

Apply the following in order; these are practical, defensible steps for production environments.

• Confirm exposure
• Check whether the host runs KVM and the affected kernel: uname -r; lsmod | grep kvm; check whether your kernel package version is listed in your distro advisory. If the distro lists a fixed package, compare installed package hashes/versions before patching.
• Patch promptly
• Apply the vendor-supplied kernel update or backport that specifically references CVE-2022-49562. Use your distribution’s standard update channels (apt/dnf/zypper) or your enterprise patch tooling to stage and deploy. Verify the package includes the CVE in its changelog or advisory note.
• Stage and validate
• Roll out patches into a small pilot before broad deployment. Validate KVM/VM behavior: guest booting, live migration, snapshots, and IO paths. Test for stability and perform post-patch reboots as required. Follow the same phased rollout guidance commonly recommended for virtualization patches.
• If you cannot patch immediately (compensating controls)
• Reduce exposure by limiting who can create or mount unmanaged VM mappings, avoid mounting untrusted VM_PFNMAP-backed files, and minimize running untrusted guests on hosts that serve multiple tenants.
• Increase monitoring for kernel oops, repeated panics, or KVM-related dmesg/log entries that could indicate someone triggering the problematic path.
• Post-patch verification
• Confirm the kernel version and that the CVE is no longer present in package changelogs. Monitor for regressions introduced by the update (live migration, storage drivers, vendor modules). Keep rollback plans available if you detect serious regressions after deployment.

Detection and incident response guidance​

• Telemetry to monitor:
• Kernel oops and panic logs traceable to KVM code paths.
• Repeated KVM or memory management errors in dmesg/syslog soon after guest operations that touch mapping/flushing (e.g., unusual use of VM_PFNMAP).
• Forensic steps if you suspect pre-patch exploitation:
• Preserve host memory and disk images.
• Export kernel traces and KVM debug logs that align with observed events.
• Look for unexpected privilege changes or persistence mechanisms on the host especially if exploitation was oriented toward denial-of-service or crash triggering; while CVE-2022-49562 primarily impacts availability, any kernel fault in an operational environment merits a thorough post-incident review.

Why this matters operationally​

• Hypervisor-layer bugs concentrate risk. KVM is a privileged kernel path that mediates guest memory — a single host instability can affect multiple guests and tenant workloads.
• The bug demonstrates the hazards of subtle address-space assumptions. Code that depends on field semantics (vm_pgoff vs base PFN) is easy to get wrong; mapping guest structures into kernel space increases the blast radius when those semantics differ. The upstream fix reduces complexity and removes one more fragile mapping.
• Small patches can have high value. The change that fixed CVE-2022-49562 is concise, but it prevents a class of incorrect physical-frame references that are both hard to reason about and potentially disruptive in production. Small commits that remove incorrect assumptions are often the safest and most durable fixes for kernel correctness issues.

Cross-checks and verification of claims​

Key claims in this write-up were verified against multiple independent sources:

• The upstream patch and technical rationale are available on the kernel mailing list and were confirmed in the kernel patch thread. That upstream record documents the code-level change from PTE-mapping to __try_cmpxchg_user().
• Distribution and vendor advisories (Ubuntu, Debian trackers, Amazon Linux Advisory Service, Red Hat entries) list CVE-2022-49562 and reflect the distribution-level remediation status. These independent trackers corroborate the CVE description and that the fix was handled as a kernel-level correction in distro packages.
• Some discrepancy exists in numerical severity (CVSS) across trackers. NVD did not publish a consistent CVSS score in some records at time of advisory publication; AWS/ALAS and OpenCVE present a medium/availability-focused score, while other aggregators have different severity translations. Because public scoring can vary with interpretation, treat scores as guidance and verify operational impact against your environment and vendor-specific advisories. Where the score or a metric is inconsistent between trackers, that point is explicitly flagged as such in this article.

Risks and potential gaps after patching​

• Patching eliminates the specific code-path error, but kernel patches can introduce regressions. Test live-migration, storage drivers, and vendor kernel modules carefully post-update. Follow the standard phased rollout recommendations and maintain rollback plans.
• Distribution backports: some distros may backport different fixes or choose not to backport this change into older kernels. Hosts running vendor kernels or long-term support branches need explicit verification that the backport exists and is applied. If a vendor marks a package “Not Affected” or “No Fix Planned,” validate whether that decision is based on configuration (e.g., a kernel built without the vulnerable path) or a mismatch in triage.
• Operational exposure window: in multi-tenant clouds or hosting environments, an unpatched host is high value. Ensure management controls (who may run guests, mount device-backed memory, or provide custom VFIO/host device mappings) are constrained to trusted admins while patches are deployed.

Practical commands and checks (quick reference)​

• Check kernel release:
• uname -r
• Check KVM presence:
• lsmod | grep kvm
• systemctl status libvirtd (if using libvirt-managed guests)
• Verify vendor advisory:
• Consult your distribution’s security tracker and search for CVE-2022-49562 in the package changelog before and after package upgrades. For example, apt changelog or rpm -q --changelog package.
• Apply patches (examples):
• Debian/Ubuntu: apt update && apt install --only-upgrade linux-image-<pkg>
• RHEL/CentOS: dnf update kernel-core

Always follow your organization’s patching runbook and test ring procedures; do not assume a package labelled “security” contains a particular fix until you confirm the changelog mentions the CVE or the upstream commit.

---

Conclusion​

CVE-2022-49562 is a textbook case where a small, precise code rewrite — replacing an ad-hoc mapping hack with a purpose-built atomic user-address primitive — materially improves kernel correctness and reduces host instability risk. The underlying vulnerability is primarily an availability/robustness problem caused by incorrect PFN assumptions in the VM_PFNMAP path; the upstream remedy is low-risk and focused. Administrators should prioritize verifying and applying distribution-supplied kernel updates that reference CVE-2022-49562, perform staged rollouts with validation of KVM and storage workflows, and harden management practices for hosts that run untrusted or multi-tenant guests while updates are deployed. Cross-check distro advisories and upstream commits for confirmation of the fix, and treat differing CVSS numbers across trackers as an operational signal to validate against local risk rather than as a definitive technical judgment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center