---
id: "CVE-2026-98717"
kind: "vulnerability"
aliases: ["CVE-2026-98717"]
title: "Linux KVM: race during memslot creation causes kernel NULL pointer dereference crash"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["kvm", "linux", "runtime", "self-hosted", "virtualization", "x86"]
not_affected_if: ["no-kvm", "no-nested-virtualization", "non-x86"]
published_at: "2026-10-18T16:17:25+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:17:28+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98717", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux KVM: race during memslot creation causes kernel NULL pointer dereference crash

A race between memslot creation and a nested guest stage-2 page fault can make KVM walk shadow page tables backed by the zero page, causing a kernel NULL pointer dereference. The sources describe a kernel oops (crash) on x86 KVM hosts; they do not describe code execution.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel version, which the sources do not name
- Check whether KVM is in use with `lsmod | grep kvm` and whether nested virtualization is enabled, for example `cat /sys/module/kvm_intel/parameters/nested` or `cat /sys/module/kvm_amd/parameters/nested`

## Fix

- Update the Linux kernel to a release that includes the upstream fix for CVE-2026-98717; the fixed version is unknown from the sources
- Reboot the host after updating so the fixed kernel is running

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98717

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Bail from shadow walks if the root is invalid or a dummy

When walking shadow page tables, immediately terminate the walk if the root
is a "dummy" root, i.e. a root whose top-level page table is backed by the
zero page, but otherwise doesn't exist.  If memslot creation races with a
stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align,
KVM will attempt to walk shadow page tables using the zero page and hit a
NULL pointer deref.

  BUG: kernel NULL pointer dereference, address: 0000000000000021
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0000 [#1] SMP
  CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm]
  Call Trace:
   <TASK>
   kvm_mmu_invalidate_addr+0x92/0xe0 [kvm]
   __kvm_inject_emulated_page_fault+0x67/0x80 [kvm]
   ept_page_fault+0x160/0x850 [kvm]
   kvm_mmu_do_page_fault+0x102/0x1f0 [kvm]
   kvm_mmu_page_fault+0x8e/0x6b0 [kvm]
   vmx_handle_exit+0x163/0x640 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm]
   kvm_vcpu_ioctl+0x2c7/0x970 [kvm]
   __x64_sys_ioctl+0x90/0xd0
   do_syscall_64+0x67/0x5f0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
  RIP: 0033:0x7f606d0b53bb

Opportunistically harden the shadow walks against fully invalid roots, but
WARN, as all callers are expected/required to pre-check for a valid root.
Don't WARN in the dummy root case as the whole point of using a dummy root
is to provide a root that's valid enough to enter the guest, i.e. it should
Just Work for all flows except those that *need* to know about dummy roots.

Alternatively, KVM could allocate a dedicated page and associated shadow
page structure for the dummy root, which is very tempting as it such an
approach should be more resilient against unexpected behavior.  But that
would be a much larger and thus riskier change than simply terminating
walks of dummy roots.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_