Skip to content
Heist/ feed
Back to feed
HighFix available

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct

Products
Kernel
Affected versions
Not specified
Fixed versions
5.15.211, 6.1.177, 6.12.95, 6.18.38, 6.6.144, 7.1.3
CVEs
CVE-2026-63807
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 11:24 UTC · Revision 1

Source evidence

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

core-osv · Original source

Published 19 Jul 2026, 12:02 UTC

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct

osv:CVE-2026-63807

Kernel

Fixed versions: 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3

Complete source record
{
  "id": "6ac5f8d917ba7a77b985bb4c30efbe3bdaee5e9191f49bdaa9a24ae4a7cd12bd",
  "url": "https://osv.dev/vulnerability/CVE-2026-63807",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct",
    "evidence": "osv:CVE-2026-63807",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "5.15.211",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.1.177",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.144",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.95",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.38",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.3",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-63807",
      "aliases": [
        "CVE-2026-63807"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "9eba50f8d7fcb61774f160890f98239fa3ab68a6"
                },
                {
                  "fixed": "7b52008023b7facf40fba3ebe92449bda8ea53b9"
                },
                {
                  "fixed": "5cab1c989f938f5e1b9a0de66486f1fc2c28479b"
                },
                {
                  "fixed": "48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8"
                },
                {
                  "fixed": "c5c29b3c268332afe67d598a034c58344540ed92"
                },
                {
                  "fixed": "18587f9831612e24cd8f24be1ec15478feff7abc"
                },
                {
                  "fixed": "b2ae3245ea44dccaa9af676b6747476951883318"
                },
                {
                  "fixed": "ef057cbf825e03b63f6edf5980f96abf3c53089d"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-63807.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.12.0"
                },
                {
                  "fixed": "5.15.211"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.16.0"
                },
                {
                  "fixed": "6.1.177"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.144"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.95"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.38"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.3"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-63807.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:28.164741334Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/18587f9831612e24cd8f24be1ec15478feff7abc",
        "https://git.kernel.org/stable/c/48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8",
        "https://git.kernel.org/stable/c/5cab1c989f938f5e1b9a0de66486f1fc2c28479b",
        "https://git.kernel.org/stable/c/7b52008023b7facf40fba3ebe92449bda8ea53b9",
        "https://git.kernel.org/stable/c/b2ae3245ea44dccaa9af676b6747476951883318",
        "https://git.kernel.org/stable/c/c5c29b3c268332afe67d598a034c58344540ed92",
        "https://git.kernel.org/stable/c/ef057cbf825e03b63f6edf5980f96abf3c53089d",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63807.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-63807",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63807.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-63807",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 494934,
  "published_at": "2026-07-19T12:02:10.759+00:00"
}