---
id: "CVE-2026-98716"
kind: "vulnerability"
aliases: ["CVE-2026-98716"]
title: "Linux KVM: SVM checks wrong MSR bitmap for nested guests"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["amd-svm", "kvm", "linux-kernel", "nested-virtualization", "runtime"]
not_affected_if: ["no-kvm-on-amd", "no-nested-virtualization"]
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:27+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98716", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux KVM: SVM checks wrong MSR bitmap for nested guests

The Linux kernel's KVM module on AMD SVM hosts can consult the wrong MSR permission bitmap when a nested guest (L2) is running, because it assumes the bitmap of vmcb02 is always active. The description does not state what an attacker gains or how the mismatch is exploited.

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

## How to check

- unknown

## Fix

- unknown

## Timeline

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

## From the sources

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

KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted

Use the MSR permission bitmap of the active VMCB instead of assuming that
KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02
if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM
needs to merge msprm01 with msrpm12.

Don't bother tracking the virtual address of the bitmap that's being used,
as __va() is cheap on x86, and caching the virtual address would introduce
yet another source of potentially stale information.

---

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