CVE-2025-38351
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-19

Last updated on: 2025-11-18

Assigner: kernel.org

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 of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way. Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-19
Last Modified
2025-11-18
Generated
2026-05-07
AI Q&A
2025-07-19
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38351
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves the Linux kernel's KVM module for x86 with Hyper-V hypercalls enabled. Specifically, when a guest requests to flush parts of its virtual TLB using certain hypercalls, it can pass non-canonical guest virtual addresses (GVAs). The system did not filter out these invalid addresses, which on Intel CPUs causes an error and warning due to the INVVPID instruction failing. This can lead to unexpected warnings and potential instability. The fix involves skipping non-canonical GVAs during processing to avoid triggering this failure.


How can this vulnerability impact me? :

If exploited, this vulnerability can cause the KVM module on Intel CPUs to trigger warnings and errors related to invalid TLB flush requests, potentially leading to instability or crashes in virtual machines running on affected systems. However, well-behaved guests typically do not request TLB flushes for non-canonical addresses, so the practical impact is limited to malformed or malicious guests causing these errors.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring system logs for warnings related to INVVPID failures, specifically messages like 'invvpid failed' and 'WARNING: CPU' from the kvm_intel module. Checking kernel logs (e.g., using 'dmesg' or 'journalctl -k') for such warnings can help identify if the issue is occurring. For example, running 'dmesg | grep invvpid' or 'journalctl -k | grep invvpid' may reveal relevant error messages.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is resolved, as the fix involves skipping non-canonical addresses during PV TLB flush in KVM guests with Hyper-V hypercalls enabled. Until the update is applied, avoid running untrusted guests that may issue invalid hypercalls. Additionally, monitoring for the described warnings can help in early detection.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart