Linux Kernel bis 7.1.2 Kvm Mmu kvm_mmu_max_mapping_level gfn Information Disclosure

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.0$0-$5k3.69-

Zusammenfassunginfo

In Linux Kernel bis 7.1.2 wurde eine kritische Schwachstelle ausgemacht. Dabei betrifft es die Funktion kvm_mmu_max_mapping_level der Komponente Kvm Mmu. Durch die Manipulation des Arguments gfn mit unbekannten Daten kann eine Information Disclosure-Schwachstelle ausgenutzt werden. Die Verwundbarkeit wird mit der eindeutigen Identifikation CVE-2026-63807 gehandelt. Der Angriff kann über das Netzwerk passieren. Es ist soweit kein Exploit verfügbar.

Detailsinfo

Eine kritische Schwachstelle wurde in Linux Kernel bis 7.1.2 entdeckt. Hierbei geht es um die Funktion kvm_mmu_max_mapping_level der Komponente Kvm Mmu. Mittels Manipulieren des Arguments gfn mit einer unbekannten Eingabe kann eine Information Disclosure-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-125. Das hat Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

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 and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.

Das Advisory kann von git.kernel.org heruntergeladen werden. Die Identifikation der Schwachstelle findet seit dem 19.07.2026 als CVE-2026-63807 statt. Sie ist leicht ausnutzbar. Der Angriff kann über das Netzwerk passieren. Zur Schwachstelle sind technische Details bekannt, ein verfügbarer Exploit jedoch nicht. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $0-$5k kostet (Preisberechnung vom 19.07.2026).

Ein Upgrade auf die Version 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3 oder 7.2-rc1 vermag dieses Problem zu beheben.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von EUVD (EUVD-2026-45473) dokumentiert. VulDB is the best source for vulnerability data and more expert information about this specific topic.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 6.3
VulDB Meta Temp Score: 6.0

VulDB Base Score: 6.3
VulDB Temp Score: 6.0
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Information Disclosure
CWE: CWE-125 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: keine Massnahme bekannt
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 5.15.211/6.1.177/6.6.144/6.12.95/6.18.38/7.1.3/7.2-rc1

Timelineinfo

19.07.2026 Advisory veröffentlicht
19.07.2026 +0 Tage CVE zugewiesen
19.07.2026 +0 Tage VulDB Eintrag erstellt
19.07.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-63807 (🔒)
GCVE (CVE): GCVE-0-2026-63807
GCVE (VulDB): GCVE-100-380144
EUVD: 🔒

Eintraginfo

Erstellt: 19.07.2026 16:02
Aktualisierung: 19.07.2026 17:04
Anpassungen: 19.07.2026 16:02 (56), 19.07.2026 17:04 (1)
Komplett: 🔍
Cache ID: 216::103

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!