{"id":66597,"date":"2025-07-19T16:31:49","date_gmt":"2025-07-19T13:01:49","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2025-38351-kvm-hyper-v-canonical-gva-vulnerability\/"},"modified":"2025-07-19T16:31:49","modified_gmt":"2025-07-19T13:01:49","slug":"cve-2025-38351-kvm-hyper-v-canonical-gva-vulnerability","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2025-38351-kvm-hyper-v-canonical-gva-vulnerability\/","title":{"rendered":"CVE-2025-38351 &#8211; KVM Hyper-V Canonical GVA Vulnerability"},"content":{"rendered":"<p><strong>CVE ID : <\/strong>CVE-2025-38351<br \/>\n<br \/>\n<strong>Published : <\/strong> July 19, 2025, 12:15 p.m. | 30\u00a0minutes ago<br \/>\n<br \/>\n<strong>Description : <\/strong>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>KVM: x86\/hyper-v: Skip non-canonical addresses during PV TLB flush<\/p>\n<p>In KVM guests with Hyper-V hypercalls enabled, the hypercalls<br \/>\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX<br \/>\nallow a guest to request invalidation of portions of a virtual TLB.<br \/>\nFor this, the hypercall parameter includes a list of GVAs that are supposed<br \/>\nto be invalidated.<\/p>\n<p>However, when non-canonical GVAs are passed, there is currently no<br \/>\nfiltering in place and they are eventually passed to checked invocations of<br \/>\nINVVPID on Intel \/ INVLPGA on AMD.  While AMD&#8217;s INVLPGA silently ignores<br \/>\nnon-canonical addresses (effectively a no-op), Intel&#8217;s INVVPID explicitly<br \/>\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():<\/p>\n<p>  invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000<br \/>\n  WARNING: CPU: 6 PID: 326 at arch\/x86\/kvm\/vmx\/vmx.c:482<br \/>\n  invvpid_error+0x91\/0xa0 [kvm_intel]\n  Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse<br \/>\n  CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)<br \/>\n  RIP: 0010:invvpid_error+0x91\/0xa0 [kvm_intel]\n  Call Trace:<br \/>\n    vmx_flush_tlb_gva+0x320\/0x490 [kvm_intel]\n    kvm_hv_vcpu_flush_tlb+0x24f\/0x4f0 [kvm]\n    kvm_arch_vcpu_ioctl_run+0x3013\/0x5810 [kvm]\n<p>Hyper-V documents that invalid GVAs (those that are beyond a partition&#8217;s<br \/>\nGVA space) are to be ignored.  While not completely clear whether this<br \/>\nruling also applies to non-canonical GVAs, it is likely fine to make that<br \/>\nassumption, and manual testing on Azure confirms &#8220;real&#8221; Hyper-V interprets<br \/>\nthe specification in the same way.<\/p>\n<p>Skip non-canonical GVAs when processing the list of address to avoid<br \/>\ntripping the INVVPID failure.  Alternatively, KVM could filter out &#8220;bad&#8221;<br \/>\nGVAs before inserting into the FIFO, but practically speaking the only<br \/>\ndownside of pushing validation to the final processing is that doing so<br \/>\nis suboptimal for the guest, and no well-behaved guest will request TLB<br \/>\nflushes for non-canonical addresses.<br \/>\n<br \/>\n<strong>Severity:<\/strong> 0.0 | NA<br \/>\n<br \/>\nVisit the link for more details, such as CVSS details, affected products, timeline, and more&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE ID : CVE-2025-38351 Published : July 19, 2025, 12:15 p.m. | 30\u00a0minutes ago Description : In the Linux kernel, the following vulnerability has been resolved: KVM: x86\/hyper-v: Skip non-canonical addresses during PV TLB flush In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-66597","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/66597","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=66597"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/66597\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=66597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=66597"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=66597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}