CVE-2026-99082 json
KVM: x86: Use active memslots for the per-vCPU MMIO cache
published 19d ago modified 12d ago also EUVD-2026-108933
- cvss
- 8.8
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 4%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Use active memslots for the per-vCPU MMIO cache
KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1.
Commit 56f17dd3fbc4 ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots.
Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO.
Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination.
Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots().
On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass.
Patch / fix
- Linux Linux 7.3
- linux Debian 13 6.12.115-2
- linux Debian 14 7.2.12-1
debian advisories DEBIAN-CVE-2026-99082
- linux Ubuntu 26.10 7.3.0-10.10
- linux-aws Ubuntu 26.10 7.3.0-1004.4
- linux-gcp Ubuntu 26.10 7.3.0-1004.4
- linux-raspi Ubuntu 26.10 7.3.0-1004.4
- linux-riscv Ubuntu 26.10 7.3.0-10.10.1
- linux-oracle Ubuntu 26.10 7.3.0-1004.4
- linux-realtime Ubuntu 26.10 7.3.0-10.10.1
ubuntu advisories UBUNTU-CVE-2026-99082
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel Azure Linux 3.0 6.6.161.1-1
azure linux advisories AZL-110987
Azure Linux vulnerability data, Copyright (c) Microsoft Corporation, from https://github.com/microsoft/AzureLinuxVulnerabilityData via OSV, under the MIT licence; changed: normalised to fixed package versions per release. MIT
- git.kernel.org/stable/c/485a5286675b15b00ee850d90eaa178cc588445f commit
- git.kernel.org/stable/c/445e3369ac8cc1b18aedc8e8f977c68a0a326fa9 commit
- git.kernel.org/stable/c/1c77d33d85786d36e56ca1b580fb55347fd65b47 commit
- git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876 commit
- git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd commit
- git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312 commit
- git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204 commit
- git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735 commit
Is CVE-2026-99082 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-99082 updated cvss 5.6
kernel: KVM: x86: Use active memslots for the per-vCPU MMIO cache
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 moreaffected: no fix planned “Out of support scope”
-
Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8, openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9affected: no fix available “Fix deferred”
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.16% chance of exploitation in the next 30 days, higher than 4% of all scored CVEs (FIRST EPSS, 2026-11-11).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 8.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/485a5286675b15b00ee850d90eaa178cc588445f
- git.kernel.org /stable/c/445e3369ac8cc1b18aedc8e8f977c68a0a326fa9
- git.kernel.org /stable/c/1c77d33d85786d36e56ca1b580fb55347fd65b47
- git.kernel.org /stable/c/a63f79d9da9468952396af73e1e53330845cf876
- git.kernel.org /stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd
- git.kernel.org /stable/c/2566780c684c9c21241d409d790087c73070f312
- git.kernel.org /stable/c/e792a9ace39d2812a5b342a1987186c7bc653204
- git.kernel.org /stable/c/b3e6212dea2e4328a841ceb37f377583176dc735
Sources
- CVE List CVE-2026-99082
- NVD CVE-2026-99082
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.