CVE-2022-49882: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache

Published May 1, 2025
·
Updated

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

KVM: Reject attempts to consume or refresh inactive gfntopfncache

Reject kvmgpccheck() and kvmgpcrefresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmunotifier invalidation due to the cache not being on the list of gfns to invalidate.

Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmunotifier events. If a relevant mmunotifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmunotifier event with active users and/or kvmgpcrefresh().

A race between KVMXENATTRTYPESHAREDINFO and KVMXENHVMEVTCHNSEND can be exploited to trigger the bug.

1. Deactivate shinfo cache:

kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO kvmgpcdeactivate kvmgpcunmap gpc->valid = false gpc->khva = NULL gpc->active = false

Result: active = false, valid = false

2. Cause cache refresh:

kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast kvmgpccheck return -EWOULDBLOCK because !gpc->valid kvmxensetevtchnfast return -EWOULDBLOCK kvmgpcrefresh hvatopfnretry gpc->valid = true gpc->khva = not NULL

Result: active = false, valid = true

3. Race ioctl KVMXENHVMEVTCHNSEND against ioctl KVMXENATTRTYPESHAREDINFO:

kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast readlock gpc->lock kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO mutexlock kvm->lock kvmxensharedinfoinit kvmgpcactivate gpc->khva = NULL kvmgpccheck [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pendingbits = shinfo->evtchnpending CRASH: testandsetbit(..., pendingbits)

Affected Software

5 affected components
Linux Kernel
Linux Linux kernel>=5.17<6.0.8
Linux Linux kernel=6.1-rc1
Linux Linux kernel=6.1-rc2
Linux Linux kernel=6.1-rc3

Event History

May 1, 2025
CVE Published
via MITRE·02:10 PM
Data Sourced
via MITRE·02:10 PM
DescriptionSeverity
Data Sourced
via NVD·03:16 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2022-49882?

The severity of CVE-2022-49882 is classified as important due to potential denial of service issues.

2

How do I fix CVE-2022-49882?

To fix CVE-2022-49882, update to the latest version of the Linux kernel where the vulnerability has been resolved.

3

What systems are impacted by CVE-2022-49882?

CVE-2022-49882 affects systems running affected versions of the Linux kernel.

4

What actions are recommended to mitigate CVE-2022-49882?

It is recommended to apply the necessary kernel updates to mitigate CVE-2022-49882.

5

What are the consequences of CVE-2022-49882?

The consequences of CVE-2022-49882 may include system instability and potential denial of service.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203