---
id: "CVE-2026-99258"
kind: "vulnerability"
aliases: ["CVE-2026-99258"]
title: "Linux kernel Hyper-V: VP index lookup writes to unallocated memory in SEV-SNP guests"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["confidential-vms", "hyper-v", "infrastructure", "linux-kernel", "sev-snp"]
not_affected_if: ["no-sev-snp", "non-hyperv", "paravisor"]
published_at: "2026-11-03T12:17:32+00:00"
first_seen_at: "2026-11-03T12:20:39+00:00"
updated_at: "2026-11-03T12:22:48+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99258", "first_seen_at": "2026-11-03T12:20:39+00:00"}]
---

# Linux kernel Hyper-V: VP index lookup writes to unallocated memory in SEV-SNP guests

In Hyper-V guests running the Linux kernel, the APIC-ID-to-VP-index lookup used a per-CPU output page that was not allocated on SEV-SNP confidential VMs without a paravisor, so the hypervisor wrote the result into guest memory the guest never allocated. The sources do not state what an attacker can do with this write.

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

## How to check

- Check the running kernel version with `uname -r` and compare it against the fixed kernel releases in the NVD entry.
- Determine whether the VM runs on Hyper-V as an SEV-SNP confidential guest with no paravisor; the sources describe this as the affected configuration.

## Timeline

- 2026-11-03T12:20:39+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99258

## From the sources

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

x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index()

hv_apicid_to_vp_index() currently uses the per-cpu hypercall input
and output pages. This function is called when running in VTL2 and
when running in an SEV-SNP CoCo VM with no paravisor. In the former
case, the output page is allocated, but in the latter case it is
not, so the hypervisor stores the output VP index in memory that has
not been allocated by the guest.

Fix this by using the input page for both input and output. The
hypercall has very small input and output, so sharing the same
page for both is straightforward. An alternative fix is to
allocate the per-cpu output page when running in an SEV-SNP CoCo
guest, but this uses significantly more memory, particularly
with larger vCPUs counts.

---

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