Vulnerability-Lookup

GHSA-58R9-CH9W-PX7W

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-24 15:32

Details

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.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-99082"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:32Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Use active memslots for the per-vCPU MMIO cache\n\nKVM tags the per-vCPU MMIO cache with a memslot generation so that a\nmemslot update invalidates cached MMIO information.  Both the fill and\nvalidation paths use kvm_memslots(), which unconditionally selects address\nspace 0, even when the vCPU is running in SMM and using address space 1.\n\nCommit 56f17dd3fbc4 (\"kvm: x86: fix stale mmio cache bug\") added the\nmemslot generation to the cache key so that a memslot update could not\nleave a stale entry valid.  When commit 699023e23965 (\"KVM: x86: add SMM\nto the MMU role, support SMRAM address space\") added the SMM address space,\nthese helpers were not converted to use the active memslots.\n\nConsequently, an update to the SMM memslots can leave an entry from the old\nSMM address space apparently valid after the vCPU returns to the normal\naddress space.  A guest can then cause an access to valid RAM at the same\nGFN to be returned to userspace as KVM_EXIT_MMIO.\n\nCompleting that exit through the VMM\u0027s RAM address space writes the backing\npage without going through KVM\u0027s write-tracking path.  If the page backs a\nnested EPT table, KVM can continue using shadow translations derived from\nthe old contents.  The WARN_ON_ONCE() in kvm_mmu_write_protect_fault()\ncatches this invalid cache and memslot combination.\n\nUse the vCPU\u0027s active memslots when caching and validating the entry.\nMemslot generations are unique across address spaces, so the generation\nalso distinguishes the normal and SMM views.  This matches the MMIO SPTE\ncache, which already uses kvm_vcpu_memslots().\n\nOn an unpatched current-mainline kernel, a regression test that fills the\ncache in SMM and updates only the SMM memslots fails the intended RAM write\nand triggers the kvm_mmu_write_protect_fault() warning.  With this change,\nthe same test completes the RAM write without a warning.  The x86/smm_test,\nset_memory_region_test, and memslot_modification_stress_test selftests also\npass.",
  "id": "GHSA-58r9-ch9w-px7w",
  "modified": "2026-10-24T15:32:51Z",
  "published": "2026-10-23T15:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99082"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-99082 (GCVE-0-2026-99082)

Vulnerability from cvelistv5 – Published: 2026-10-23 12:45 – Updated: 2026-10-24 14:10

Title

KVM: x86: Use active memslots for the per-vCPU MMIO cache

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.

Severity

8.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 7056 records in the last 180 days details

References

5 references

URL	Tags
https://git.kernel.org/stable/c/a63f79d9da9468952…
https://git.kernel.org/stable/c/7fd4e64f4bbc8c35a…
https://git.kernel.org/stable/c/2566780c684c9c212…
https://git.kernel.org/stable/c/e792a9ace39d2812a…
https://git.kernel.org/stable/c/b3e6212dea2e4328a…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 699023e239658e62da6f42f47d31b54788521ec1 , < a63f79d9da9468952396af73e1e53330845cf876 (git) Affected: 699023e239658e62da6f42f47d31b54788521ec1 , < 7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd (git) Affected: 699023e239658e62da6f42f47d31b54788521ec1 , < 2566780c684c9c21241d409d790087c73070f312 (git) Affected: 699023e239658e62da6f42f47d31b54788521ec1 , < e792a9ace39d2812a5b342a1987186c7bc653204 (git) Affected: 699023e239658e62da6f42f47d31b54788521ec1 , < b3e6212dea2e4328a841ceb37f377583176dc735 (git)
Linux	Linux	Affected: 4.2 Unaffected: 0 , < 4.2 (semver) Unaffected: 6.6.160 , ≤ 6.6.* (semver) Unaffected: 6.12.114 , ≤ 6.12.* (semver) Unaffected: 6.18.58 , ≤ 6.18.* (semver) Unaffected: 7.2.12 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/x86.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "a63f79d9da9468952396af73e1e53330845cf876",
              "status": "affected",
              "version": "699023e239658e62da6f42f47d31b54788521ec1",
              "versionType": "git"
            },
            {
              "lessThan": "7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd",
              "status": "affected",
              "version": "699023e239658e62da6f42f47d31b54788521ec1",
              "versionType": "git"
            },
            {
              "lessThan": "2566780c684c9c21241d409d790087c73070f312",
              "status": "affected",
              "version": "699023e239658e62da6f42f47d31b54788521ec1",
              "versionType": "git"
            },
            {
              "lessThan": "e792a9ace39d2812a5b342a1987186c7bc653204",
              "status": "affected",
              "version": "699023e239658e62da6f42f47d31b54788521ec1",
              "versionType": "git"
            },
            {
              "lessThan": "b3e6212dea2e4328a841ceb37f377583176dc735",
              "status": "affected",
              "version": "699023e239658e62da6f42f47d31b54788521ec1",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kvm/x86.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.2"
            },
            {
              "lessThan": "4.2",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.160",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.114",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.58",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.160",
                  "versionStartIncluding": "4.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.114",
                  "versionStartIncluding": "4.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.58",
                  "versionStartIncluding": "4.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.12",
                  "versionStartIncluding": "4.2",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "4.2",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Use active memslots for the per-vCPU MMIO cache\n\nKVM tags the per-vCPU MMIO cache with a memslot generation so that a\nmemslot update invalidates cached MMIO information.  Both the fill and\nvalidation paths use kvm_memslots(), which unconditionally selects address\nspace 0, even when the vCPU is running in SMM and using address space 1.\n\nCommit 56f17dd3fbc4 (\"kvm: x86: fix stale mmio cache bug\") added the\nmemslot generation to the cache key so that a memslot update could not\nleave a stale entry valid.  When commit 699023e23965 (\"KVM: x86: add SMM\nto the MMU role, support SMRAM address space\") added the SMM address space,\nthese helpers were not converted to use the active memslots.\n\nConsequently, an update to the SMM memslots can leave an entry from the old\nSMM address space apparently valid after the vCPU returns to the normal\naddress space.  A guest can then cause an access to valid RAM at the same\nGFN to be returned to userspace as KVM_EXIT_MMIO.\n\nCompleting that exit through the VMM\u0027s RAM address space writes the backing\npage without going through KVM\u0027s write-tracking path.  If the page backs a\nnested EPT table, KVM can continue using shadow translations derived from\nthe old contents.  The WARN_ON_ONCE() in kvm_mmu_write_protect_fault()\ncatches this invalid cache and memslot combination.\n\nUse the vCPU\u0027s active memslots when caching and validating the entry.\nMemslot generations are unique across address spaces, so the generation\nalso distinguishes the normal and SMM views.  This matches the MMIO SPTE\ncache, which already uses kvm_vcpu_memslots().\n\nOn an unpatched current-mainline kernel, a regression test that fills the\ncache in SMM and updates only the SMM memslots fails the intended RAM write\nand triggers the kvm_mmu_write_protect_fault() warning.  With this change,\nthe same test completes the RAM write without a warning.  The x86/smm_test,\nset_memory_region_test, and memslot_modification_stress_test selftests also\npass."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The attacker drives guest memory accesses through KVM_RUN via kvm_vcpu_ioctl()-\u003ekvm_arch_vcpu_ioctl_run()-\u003ehandle_ept_violation()/handle_ept_misconfig()-\u003ekvm_mmu_page_fault(), reaching the patched MMIO-cache helpers; no network protocol carries the input.\nAC:L - A malicious L1 can deterministically enter SMM, fault on an unmapped GFN to fill the cache, alter Q35 SMRAM mappings, execute RSM, and write the same GFN; this requires no race, and the complete sequence was reproduced with nested VMX/EPT.\nPR:L - The demonstrated escape needs kernel-level control of the L1 guest to manage SMM and EPT12, but that is tenant-granted guest privilege relative to host KVM; neither kvm_mmu_page_fault() nor vcpu_match_mmio_gen() requires host administrative capability.\nUI:N - The malicious L1 performs the SMM access, Q35 SMRAM reconfiguration, RSM, nested-EPT update, and final RAM write itself, without any action by a host user or administrator.\nS:C - The flaw originates in host KVM\u0027s per-vCPU MMIO cache, while stale shadow EPT translations permit the guest to access host kernel memory, crossing the guest-to-host virtualization boundary.\nC:H - Bypassing kvm_page_track_write() leaves EPT02 translations derived from old EPT12 contents; on affected Linux 6.1.74 this exact stale mapping was demonstrated to provide arbitrary reads of host physical and kernel memory.\nI:H - The same stale EPT02 translations were demonstrated to provide arbitrary host-memory writes and host-kernel code execution after emulator_write_emulated() incorrectly routed the tracked EPT12 write through KVM_EXIT_MMIO.\nA:H - Arbitrary host-kernel writes and code execution can crash the host and all co-resident VMs; independently, the invalid cache state reaches WARN_ON_ONCE() in kvm_mmu_write_protect_fault(), which panics hardened panic_on_warn hosts."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-24T14:10:23.875Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876"
        },
        {
          "url": "https://git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd"
        },
        {
          "url": "https://git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312"
        },
        {
          "url": "https://git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204"
        },
        {
          "url": "https://git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735"
        }
      ],
      "title": "KVM: x86: Use active memslots for the per-vCPU MMIO cache",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-99082",
    "datePublished": "2026-10-23T12:45:00.798Z",
    "dateReserved": "2026-09-25T10:25:14.390Z",
    "dateUpdated": "2026-10-24T14:10:23.875Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted