CVE-2025-38351

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush<br /> <br /> In KVM guests with Hyper-V hypercalls enabled, the hypercalls<br /> HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX<br /> allow a guest to request invalidation of portions of a virtual TLB.<br /> For this, the hypercall parameter includes a list of GVAs that are supposed<br /> to be invalidated.<br /> <br /> However, when non-canonical GVAs are passed, there is currently no<br /> filtering in place and they are eventually passed to checked invocations of<br /> INVVPID on Intel / INVLPGA on AMD. While AMD&amp;#39;s INVLPGA silently ignores<br /> non-canonical addresses (effectively a no-op), Intel&amp;#39;s INVVPID explicitly<br /> signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():<br /> <br /> invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000<br /> WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482<br /> invvpid_error+0x91/0xa0 [kvm_intel]<br /> Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse<br /> CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)<br /> RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]<br /> Call Trace:<br /> vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]<br /> kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]<br /> <br /> Hyper-V documents that invalid GVAs (those that are beyond a partition&amp;#39;s<br /> GVA space) are to be ignored. While not completely clear whether this<br /> ruling also applies to non-canonical GVAs, it is likely fine to make that<br /> assumption, and manual testing on Azure confirms "real" Hyper-V interprets<br /> the specification in the same way.<br /> <br /> Skip non-canonical GVAs when processing the list of address to avoid<br /> tripping the INVVPID failure. Alternatively, KVM could filter out "bad"<br /> GVAs before inserting into the FIFO, but practically speaking the only<br /> downside of pushing validation to the final processing is that doing so<br /> is suboptimal for the guest, and no well-behaved guest will request TLB<br /> flushes for non-canonical addresses.