CVE-2026-99258 in Linux
Summary
by MITRE • 11/03/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel contains a critical vulnerability within the x86 Hyper-V hypervisor interface code that manifests as a use-after-free or invalid memory access condition when operating under specific virtualization environments. The function hv_apicid_to_vp_index is responsible for mapping an Advanced Programmable Interrupt Controller identifier to a Virtual Processor index, a necessary step for interrupt delivery and scheduling in virtualized systems. This routine relies on per-cpu hypercall input and output pages provided by the hypervisor interface layer. Under normal circumstances within standard Hyper-V guests, these buffers are correctly allocated and managed. However, the vulnerability arises when the guest operates in two distinct high-security configurations: specifically when running at Virtualization Trust Level 2 (VTL2) or when operating as a Secure Encrypted Virtualization with Secure Nested Paging Co-Processor VM without an intervening paravisor. In these scenarios, the kernel fails to allocate the dedicated per-cpu output page required by the hypercall mechanism, yet it proceeds to invoke the function which expects this buffer to exist for storing results returned from the hypervisor.
This architectural oversight leads to a severe memory safety violation where the hypervisor attempts to write the resulting VP index into a memory location that has not been allocated or mapped by the guest operating system. In VTL2 environments, while the output page is technically allocated, the context switching and isolation boundaries can still introduce risks if the buffer management logic is inconsistent across different execution levels. More critically, in SEV-SNP CoCo VMs without a paravisor, the absence of an allocated output page means that any write operation by the hypervisor targets undefined or unmapped memory regions. This constitutes a classic invalid memory access vulnerability where kernel-space code interacts with resources outside its authorized allocation boundaries. Such behavior can lead to immediate system crashes due to general protection faults or page faults, resulting in a denial of service for the virtual machine. In more complex scenarios involving shared physical pages or specific hypervisor implementations, this could potentially allow an attacker who controls the guest workload to influence memory contents unpredictably, although the primary impact here is stability and integrity rather than direct privilege escalation through standard exploitation vectors.
From a classification perspective, this flaw aligns with CWE-125 Out-of-bounds Read if interpreted as reading uninitialized data, but more accurately reflects CWE-787 Out-of-bounds Write due to the hypervisor writing output data into unallocated memory space controlled by the guest kernel's expectations rather than actual allocation. In terms of attack vectors and mitigation strategies within the MITRE ATT&CK framework for virtualization environments, this relates to techniques involving resource manipulation or exploitation of hypervisor-guest interface assumptions. The vulnerability highlights the complexity of maintaining secure boundaries in nested virtualization and confidential computing architectures where traditional paravirtualized interfaces are bypassed or modified. Security analysts should note that such bugs often stem from incomplete handling of edge cases in hardware-assisted security features like AMD SEV-SNP, which enforce strict memory encryption and attestation but require precise software implementation to avoid breaking the isolation guarantees they provide.
The resolution implemented by the Linux kernel maintainers addresses this issue by modifying hv_apicid_to_vp_index to utilize the hypercall input page for both input parameters and output results. This approach leverages the fact that the data exchanged during this specific hypercall is minimal, making it safe and efficient to share a single buffer rather than maintaining separate allocations. By reusing the existing input page structure, the code eliminates the dependency on an unallocated output page in SEV-SNP environments while avoiding the significant memory overhead associated with allocating additional per-cpu pages for every virtual CPU core. This fix is particularly important for systems with large numbers of vCPUs, where maintaining separate buffers would consume substantial amounts of kernel memory and potentially impact performance due to increased cache pressure and allocation latency. The alternative solution of conditionally allocating the output page was rejected because it introduces unnecessary complexity and resource consumption without addressing the root cause of the interface assumption mismatch.
To mitigate similar vulnerabilities in other systems or during future development, engineers must ensure that all hypercall interfaces strictly validate buffer availability before execution, especially when operating under confidential computing constraints where memory layout is tightly controlled by hardware security modules. Developers should adopt a defense-in-depth strategy for hypervisor interactions, verifying that every expected output buffer is properly mapped and allocated prior to invoking the call. Regular auditing of virtualization-specific code paths against different guest configurations, including VTL levels and secure enclaves, is essential to prevent these types of logical errors from reaching production kernels. Furthermore, static analysis tools should be configured to detect potential out-of-bounds accesses in kernel modules that interact with hypervisor interfaces, ensuring that memory safety constraints are enforced even when performance optimizations might otherwise encourage shared buffer usage without adequate safeguards.