Cloudanix VulnDB

CVE-2026-99258

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's handling of certain Hyper-V operations could let the hypervisor write data into memory the guest never set aside, which might crash the system or allow an attacker inside the virtual machine to take further control.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The hv_apicid_to_vp_index() hypercall handler writes its result into a per-CPU output page that has not been allocated when the guest runs as an SEV-SNP confidential VM without a paravisor, producing an out-of-bounds write into guest memory that the hypervisor controls.

Why it matters to the business

A guest kernel running under Hyper-V in an SEV-SNP environment can experience memory corruption, leading to crashes, unpredictable behavior, or potential privilege escalation within the VM; the issue affects any deployment that uses this code path and has not yet applied the upstream fix.

How an attack unfolds

An attacker with the ability to trigger hv_apicid_to_vp_index() (for example by causing APIC ID to VP index translation while the guest is executing in VTL2 or inside an SEV-SNP CoCo VM) causes the hypervisor to store a VP index value into memory the guest never allocated, corrupting adjacent kernel structures.

How to fix it

Update to a Linux kernel containing the referenced commit that re-uses the input page for both input and output in hv_apicid_to_vp_index(); rebuild and deploy the fixed kernel on all affected Hyper-V guests that use SEV-SNP confidential VMs.

How to confirm the fix worked

Verify the running kernel contains the fix for hv_apicid_to_vp_index() by inspecting the source or checking the kernel build identifier against the upstream commit; confirm that the per-CPU output page allocation path is no longer taken under SEV-SNP conditions.

Typical attack path

  1. Obtain code execution or sufficient privileges inside a Linux guest running on Hyper-V under SEV-SNP without a paravisor
  2. Force execution of hv_apicid_to_vp_index() via APIC ID translation or related hypercall paths
  3. Trigger the hypercall so the hypervisor writes the output into the unallocated per-CPU page
  4. Leverage the resulting memory corruption for denial of service or further kernel exploitation

How to detect it

Examine kernel logs for unexpected hypercall failures or page-faults originating from hv_apicid_to_vp_index(); review dmesg and /var/log/kern.log around the time of any SEV-SNP VM boot or APIC-related hypercalls for signs of memory corruption.

What your security team should do

  • Prioritize kernel updates for all SEV-SNP confidential workloads on Hyper-V
  • Monitor upstream stable branches and distribution security feeds for the backported patch
  • Test the updated kernel in staging environments that replicate SEV-SNP CoCo VM configurations before broad rollout

The record

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.

Affected packages

Ecosystem Package Introduced Fixed