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

KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk

__kvm_rmap_lock() deliberately elides the rmap lock when it observes an
empty rmap. In that case kvm_rmap_lock_readonly() also re-enables
preemption and returns zero, so the caller holds neither the rmap lock
nor a preemption reference. The elision documents the invariant it
relies on:

* Elide the lock if the rmap is empty, as lockless walkers (read-only
* mode) don't need to (and can't) walk an empty rmap, nor can they add
* entries to the rmap. I.e. the only paths that process empty rmaps
* do so while holding mmu_lock for write, and are mutually exclusive.

kvm_rmap_age_gfn_range() ignores the returned value and unconditionally
enters for_each_rmap_spte_lockless(). The iterator started with
rmap_get_first(), which re-reads rmap_head->val rather than using the
value returned by the lock. If a writer populates the rmap between the
lock's read and the iterator's re-read, the aging path walks the newly
installed rmap without holding its lock.

For a KVM_RMAP_MANY rmap this leaves the walker following a
pte_list_desc chain that it never locked. A writer holding mmu_lock for
write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle
path, or any rmap zap) via kmem_cache_free() while the walk is in
progress, giving a slab use-after-free. Nothing serialises the two: the
aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y,
and the rmap lock that would otherwise exclude the writer was elided.
Because the empty path re-enables preemption, the interval between the
two reads can span an arbitrary scheduling delay.

Fix the class of bug by having the lockless walk consume the value
returned by the lock instead of re-reading the rmap. Split
rmap_get_first() into __rmap_get_first(), which starts an iterator from
an already-read rmap value, and make for_each_rmap_spte_lockless() take
that value and call __rmap_get_first() directly.
kvm_rmap_age_gfn_range() passes the value returned by
kvm_rmap_lock_readonly(): when the lock was elided the value is zero,
__rmap_get_first() returns NULL, and the walk is skipped. No lockless
walker re-reads the rmap, so the lock-elision invariant cannot be
violated, and no lock()-without-paired-unlock() path is added to the
aging code.
Published: 2026-09-16
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Privilege Escalation (Kernel)
Action: Apply patch
AI Analysis

Impact

The vulnerability is a use‑after‑free flaw in the Linux kernel's KVM subsystem. During lockless read‑only rmap walks, the code may read stale rmap entries after a writer frees the underlying memory, allowing an attacker to trigger a kernel memory corruption. An attacker could exploit this to execute arbitrary code as the privileged host, effectively causing a kernel‑level privilege escalation.

Affected Systems

The flaw affects all Linux kernel releases that run KVM with the CONFIG_KVM_MMU_LOCKLESS_AGING option enabled, as the bug is triggered only in that configuration. Since the affected products are listed generically as Linux kernel, any distribution that includes a KVM implementation with this configuration may be vulnerable; the specific version range is not provided in the CVE data.

Risk and Exploitability

The CVSS score of 8.8 indicates high severity, while the EPSS score of less than 1% suggests a low but non‑zero likelihood of exploitation. The vulnerability is not currently listed in the CISA KEV catalog. Attackers would need to access the KVM environment, likely from a guest VM, and obtain control over memory referenced by the rmap to trigger the use‑after‑free. The lack of serialization between readers and writers during aging walks makes the flaw exploitable under normal scheduling conditions.

Generated by OpenCVE AI on September 18, 2026 at 07:48 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the posted fix, which consumes the locked rmap value during lockless walks.
  • If the patch cannot be applied immediately, temporarily disable the CONFIG_KVM_MMU_LOCKLESS_AGING option by recompiling the kernel or via a module parameter, reverting the system to a serialised rmap traversal.
  • Restrict access to the KVM hypervisor by limiting VMs to trusted users or using virtualization isolation features, reducing the attack surface for guest‑to‑host exploitation.

Generated by OpenCVE AI on September 18, 2026 at 07:48 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 08:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-367
CWE-416

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 8.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H'}

Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk __kvm_rmap_lock() deliberately elides the rmap lock when it observes an empty rmap. In that case kvm_rmap_lock_readonly() also re-enables preemption and returns zero, so the caller holds neither the rmap lock nor a preemption reference. The elision documents the invariant it relies on: * Elide the lock if the rmap is empty, as lockless walkers (read-only * mode) don't need to (and can't) walk an empty rmap, nor can they add * entries to the rmap. I.e. the only paths that process empty rmaps * do so while holding mmu_lock for write, and are mutually exclusive. kvm_rmap_age_gfn_range() ignores the returned value and unconditionally enters for_each_rmap_spte_lockless(). The iterator started with rmap_get_first(), which re-reads rmap_head->val rather than using the value returned by the lock. If a writer populates the rmap between the lock's read and the iterator's re-read, the aging path walks the newly installed rmap without holding its lock. For a KVM_RMAP_MANY rmap this leaves the walker following a pte_list_desc chain that it never locked. A writer holding mmu_lock for write may free that chain (e.g. kvm_zap_all_rmap_sptes() on the recycle path, or any rmap zap) via kmem_cache_free() while the walk is in progress, giving a slab use-after-free. Nothing serialises the two: the aging path runs without mmu_lock when CONFIG_KVM_MMU_LOCKLESS_AGING=y, and the rmap lock that would otherwise exclude the writer was elided. Because the empty path re-enables preemption, the interval between the two reads can span an arbitrary scheduling delay. Fix the class of bug by having the lockless walk consume the value returned by the lock instead of re-reading the rmap. Split rmap_get_first() into __rmap_get_first(), which starts an iterator from an already-read rmap value, and make for_each_rmap_spte_lockless() take that value and call __rmap_get_first() directly. kvm_rmap_age_gfn_range() passes the value returned by kvm_rmap_lock_readonly(): when the lock was elided the value is zero, __rmap_get_first() returns NULL, and the walk is skipped. No lockless walker re-reads the rmap, so the lock-elision invariant cannot be violated, and no lock()-without-paired-unlock() path is added to the aging code.
Title KVM: x86/mmu: Consume the locked rmap value in the lockless rmap walk
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-16T14:40:18.937Z

Reserved: 2026-09-11T19:38:34.775Z

Link: CVE-2026-89928

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:02.060

Modified: 2026-09-16T15:18:18.667

Link: CVE-2026-89928

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T08:00:06Z

Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition

  • CWE-416

    Use After Free