{"id":"CVE-2026-99258","kind":"vulnerability","aliases":["CVE-2026-99258"],"related":[],"title":"Linux kernel Hyper-V: VP index lookup writes to unallocated memory in SEV-SNP guests","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nx86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index()\n\nhv_apicid_to_vp_index() currently uses the per-cpu hypercall input\nand output pages. This function is called when running in VTL2 and\nwhen running in an SEV-SNP CoCo VM with no paravisor. In the former\ncase, the output page is allocated, but in the latter case it is\nnot, so the hypervisor stores the output VP index in memory that has\nnot been allocated by the guest.\n\nFix this by using the input page for both input and output. The\nhypercall has very small input and output, so sharing the same\npage for both is straightforward. An alternative fix is to\nallocate the per-cpu output page when running in an SEV-SNP CoCo\nguest, but this uses significantly more memory, particularly\nwith larger vCPUs counts.","summary":"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.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["confidential-vms","hyper-v","infrastructure","linux-kernel","sev-snp"],"not_affected_if":["no-sev-snp","non-hyperv","paravisor"],"how_to_check":"- Check the running kernel version with `uname -r` and compare it against the fixed kernel releases in the NVD entry.\n- 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.","fix":null,"status":"open","published_at":"2026-11-03T12:17:32+00:00","first_seen_at":"2026-11-03T12:20:39+00:00","triaged_at":"2026-11-03T12:22:48+00:00","updated_at":"2026-11-03T12:22:48+00:00","category":"infrastructure","confidence":0.4,"triage":{"at":"2026-11-03T12:22:48Z","model":"claude-haiku-5-5","output":{"fix":"unknown","reach":"unknown","title":"Linux kernel Hyper-V: VP index lookup writes to unallocated memory in SEV-SNP guests","impact":"medium","summary":"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.","audience":"businesses","category":"infrastructure","nicknames":[],"who_cares":["linux-kernel","hyper-v","sev-snp","confidential-vms"],"confidence":0.4,"fix_status":"unknown","needs_auth":"unknown","worst_case":"unknown; the sources describe a write to unallocated guest memory","analyst_note":"Check the NVD entry and the upstream kernel commit for the exploit impact, the fixed kernel versions and whether the write can be triggered from the guest.","how_to_check":"- Check the running kernel version with `uname -r` and compare it against the fixed kernel releases in the NVD entry.\n- 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.\n- unknown for any other check, as the sources do not say more.","plain_action":"","needs_analyst":true,"not_affected_if":["non-hyperv","no-sev-snp","paravisor"],"who_is_affected":"The flaw is in the Linux kernel's Hyper-V code path that runs in VTL2 and in SEV-SNP confidential VMs without a paravisor, where the output page is missing. Teams running Linux guests on Hyper-V with confidential computing should look at it; ordinary Linux guests on Hyper-V or other hypervisors are outside the described path. The sources do not describe the exploit conditions further.","user_interaction":"unknown","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.000787,"input_tokens":4321,"output_tokens":709,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':19A,22A '-99258':20A,23A 'alloc':64B,86B,169C,192C,230C 'altern':226C 'apic':48B 'apic-id-to-vp-index':47B 'apicid':120C,125C 'attack':94B 'avoid':111C 'call':143C 'case':164C,174C 'coco':156C,244C 'confidenti':25B,69B 'confidential-vm':24B 'count':256C 'cpu':58B,115C,134C,234C 'current':129C 'cve':18A,21A 'fix':196C,227C 'follow':105C 'former':163C 'function':141C 'guest':17A,41B,81B,84B,195C,245C 'hv':119C,124C 'hyper':4A,28B,39B 'hyper-v':3A,27B,38B 'hypercal':135C,209C 'hypervisor':76B,180C 'id':49B 'index':7A,52B,123C,128C,185C 'infrastructur':30B 'input':136C,201C,205C,213C 'kernel':2A,33B,45B,103C 'larger':254C 'latter':173C 'linux':1A,32B,44B,102C 'linux-kernel':31B 'lookup':8A,53B 'memori':12A,82B,187C,251C 'never':85B 'output':59B,116C,138C,166C,183C,207C,215C,235C 'page':60B,117C,139C,167C,202C,220C,236C 'paravisor':73B,160C 'particular':252C 'per':57B,114C,133C,233C 'per-cpu':56B,113C,132C,232C 'resolv':109C 'result':79B 'run':42B,145C,150C,238C 'sev':15A,35B,67B,154C,242C 'sev-snp':14A,34B,66B,153C,241C 'share':217C 'signific':249C 'small':212C 'snp':16A,36B,68B,155C,243C 'sourc':88B 'state':91B 'store':181C 'straightforward':224C 'unalloc':11A 'use':54B,112C,130C,199C,248C 'v':5A,29B,40B 'vcpus':255C 'vm':157C 'vms':26B,70B 'vp':6A,51B,122C,127C,184C 'vtl2':147C 'vulner':106C 'without':71B 'write':9A,99B 'wrote':77B 'x86/hyperv':110C","nicknames":[],"mitigations":[],"who_affected":"The flaw is in the Linux kernel's Hyper-V code path that runs in VTL2 and in SEV-SNP confidential VMs without a paravisor, where the output page is missing. Teams running Linux guests on Hyper-V with confidential computing should look at it; ordinary Linux guests on Hyper-V or other hypervisors are outside the described path. The sources do not describe the exploit conditions further.","tier":"C","verified":{},"analyst_revisit_at":null,"fix_status":"unknown","audience":"businesses","plain_action":null,"pkeys":[],"ptokens":[],"labels":["confidentialvms","hyperv","infrastructure","linuxkernel","sevsnp","unknown"],"first_public_at":"2026-11-03T12:17:32+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-99258","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99258","severity":null,"published_at":"2026-11-03T12:17:32+00:00","modified_at":"2026-11-03T12:17:32+00:00","first_seen_at":"2026-11-03T12:20:39+00:00","fetched_at":"2026-11-03T12:20:39+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}