CVE-2022-49884
published 2025-05-01CVE-2022-49884: In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock…
PriorityP415medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.12%
2.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_cache lock initialization to another helper and
call the new helper during VM/vCPU creation. There are race
conditions possible due to kvm_gfn_to_pfn_cache_init()'s
ability to re-initialize the cache's locks.
For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and
kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.
(thread 1) | (thread 2)
|
kvm_xen_set_evtchn_fast |
read_lock_irqsave(&gpc->lock, ...) |
| kvm_gfn_to_pfn_cache_init
| rwlock_init(&gpc->lock)
read_unlock_irqrestore(&gpc->lock, ...) |
Rename "cache_init" and "cache_destroy" to activate+deactivate to
avoid implying that the cache really is destroyed/freed.
Note, there more races in the newly named kvm_gpc_activate() that will
be addressed separately.
[sean: call out that this is a bug fix]
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.8-1 (bookworm) | linux 6.0.8-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 982ed0de4753ed6e71dbd40f82a5a066baf133ed < 61242001d6c9c253df7645dab090842d8da08764 | 61242001d6c9c253df7645dab090842d8da08764 |
| linux | linux | >= 982ed0de4753ed6e71dbd40f82a5a066baf133ed < 52491a38b2c2411f3f0229dc6ad610349c704a41 | 52491a38b2c2411f3f0229dc6ad610349c704a41 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.0.8-1 | 6.0.8-1 |
| linux | linux_kernel | >= 0 < 6.0.8-1 | 6.0.8-1 |
| linux | linux_kernel | >= 0 < 6.0.8-1 | 6.0.8-1 |
| linux | linux_kernel | >= 5.17 < 6.0.8 | 6.0.8 |
CVSS provenance
nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_debian4.7MEDIUM
vendor_redhat4.7MEDIUM
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.
Red Hat
kernel: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
vendor_redhat·2025-05-01·CVSS 4.7
CVE-2022-49884 [MEDIUM] CWE-362 kernel: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
kernel: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_cache lock initialization to another helper and
call the new helper during VM/vCPU creation. There are race
conditions possible due to kvm_gfn_to_pfn_cache_init()'s
ability to re-initialize the cache's locks.
For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and
kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.
(thread 1) | (thread 2)
|
kvm_xen_set_evtchn_fast |
read_lock_irqsave(&gpc->lock, ...) |
| kvm_gfn_to_pfn_cache_init
| rwlock_init(&gpc->lock)
read_unlock_irqrestore(&gpc->lock, ...) |
Rename "cache_init" and "cache_destroy" to activate+deactivate
Debian
CVE-2022-49884: linux - In the Linux kernel, the following vulnerability has been resolved: KVM: Initia...
vendor_debian·2022·CVSS 4.7
CVE-2022-49884 [MEDIUM] CVE-2022-49884: linux - In the Linux kernel, the following vulnerability has been resolved: KVM: Initia...
In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvm_gfn_to_pfn_cache_init()'s ability to re-initialize the cache's locks. For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock. (thread 1) | (thread 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Rename "cache_init" and "cache_destroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed. Note, t
OSV
CVE-2022-49884: In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cac
osv·2025-05-01·CVSS 4.7
CVE-2022-49884 [MEDIUM] CVE-2022-49884: In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cac
In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvm_gfn_to_pfn_cache_init()'s ability to re-initialize the cache's locks. For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock. (thread 1) | (thread 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Rename "cache_init" and "cache_destroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed. Note, t
GHSA
GHSA-4m85-4x3p-6jmv: In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_c
ghsa_unreviewed·2025-05-01
CVE-2022-49884 [MEDIUM] CWE-362 GHSA-4m85-4x3p-6jmv: In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_c
In the Linux kernel, the following vulnerability has been resolved:
KVM: Initialize gfn_to_pfn_cache locks in dedicated helper
Move the gfn_to_pfn_cache lock initialization to another helper and
call the new helper during VM/vCPU creation. There are race
conditions possible due to kvm_gfn_to_pfn_cache_init()'s
ability to re-initialize the cache's locks.
For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and
kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock.
(thread 1) | (thread 2)
|
kvm_xen_set_evtchn_fast |
read_lock_irqsave(&gpc->lock, ...) |
| kvm_gfn_to_pfn_cache_init
| rwlock_init(&gpc->lock)
read_unlock_irqrestore(&gpc->lock, ...) |
Rename "cache_init" and "cache_destroy" to activate+deactivate to
avoid implying that the cache really is destroyed/freed.
N
No detection rules found.
No public exploits indexed.
2025-05-01
Published