Look up another CVE · open CVE-2026-80726 in the interactive tracker

CVE-2026-80726

KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page

9.3 EPSS 0.1% AV:L

Published 2026-09-03 (2 months ago) by the Linux kernel CNA. Subsystem arch/x86. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-80726 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	fixedDLA-4777-1 · 2026-09-08 · text	6.1.187-1	Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.105-1	Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.9-1	Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.9-1	Update the kernel and reboot. Fixed in 7.1.9-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4788-1 · 2026-09-19 · text	6.12.107-1~deb12u1	Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add() instead of list_move() when processing an invalid shadow page, i.e. makes a bad situation far worse. Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page. ================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853 CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

arch/x86/kvm/mmu/mmu.c

What this is: KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)MAINTAINERS section matched on arch/x86/kvm/*/ · kvm@vger.kernel.org · Supported

Show whether Debian builds this, per release

Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.

bookworm, trixie, forky, sid, bookworm · linux-6.12?

?: not established - no Makefile entry for the affected file

Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-03 (2 months ago)source
CVSS: 9.3 critical
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.14%, higher than 2.8% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: arch/x86

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
2.6.30	5.15.222	ec4eb5c2ef96
2.6.30	6.1.183	9b7984692c18
2.6.30	6.6.152	f33ecb89d352
2.6.30	6.12.104	0af4711862c5
2.6.30	6.18.45	66bc868a33cf
2.6.30	7.1.9	9f7760a2e962
2.6.30	7.2	5ec42d57655c

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4788-1	2026-09-19	bookworm 6.12.107-1~deb12u1	tracker
DLA-4777-1	2026-09-08	bookworm 6.1.187-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The bug is reached only through host KVM x86 shadow-MMU handling on the KVM_RUN ioctl path (kvm_arch_vcpu_ioctl_run -> kvm_mmu_page_fault/kvm_mmu_load -> __kvm_mmu_get_shadow_page), driven by guest page faults and root reloads, not by remote network or physical input.
AC:LAttack complexity, low: The reproducer (UID 1000) triggers this reliably by combining guest page-table churn with MMU reclaim (make_mmu_pages_available/kvm_mmu_zap_oldest_mmu_pages) so an in-use root is zapped invalid while children are still created; the attacker controls both fault and reclaim sides of the race.
PR:NPrivileges required, none: Exploitation requires only code running inside an already-running KVM guest (or equivalent guest-driven KVM_RUN activity); no host root, CAP_SYS_ADMIN, or direct /dev/kvm access is needed beyond what any cloud VM tenant or compromised guest process already has.
UI:NUser interaction, none: Once the attacker can execute in the guest, triggering the fault/reclaim sequence is entirely self-driven through guest memory and paging behavior with no action required from another user or administrator.
S:CScope, changed: Corrupting host KVM MMU active_mmu_pages/list state from guest-controlled faults crosses the guest-to-host virtualization boundary and can compromise the host kernel beyond the guest security domain, enabling VM escape-class impact.
C:HConfidentiality impact, high: The demonstrated slab use-after-free and broken active-list invariant (invalid children left linked while __kvm_mmu_prepare_zap_page uses list_add instead of list_move) provide attacker-influenced host heap corruption that can be leveraged for arbitrary kernel memory reads.
I:HIntegrity impact, high: The same UAF and doubly-linked list corruption on host kvm_mmu_page objects are writable memory-corruption primitives suitable for control-flow or structure hijacking, not merely benign accounting errors.
A:HAvailability impact, high: KASAN reports a host slab UAF with an 8-byte write in __kvm_mmu_get_shadow_page, and list corruption on active_mmu_pages can cause host oops, panic, or hang, denying service to the host and co-located VMs.