Linux Kernel up to 7.2.9/7.3-rc5 KVM SVM svm_flush_tlb_asid information disclosure

Summaryinfo

A vulnerability categorized as problematic has been discovered in Linux Kernel up to 7.2.9/7.3-rc5. Impacted is the function svm_flush_tlb_asid of the component KVM SVM. Executing a manipulation can lead to information disclosure. The identification of this vulnerability is CVE-2026-98715. The attack can only be executed locally. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.2.9/7.3-rc5. It has been declared as problematic. This vulnerability affects the function svm_flush_tlb_asid of the component KVM SVM. The manipulation with an unknown input leads to a information disclosure vulnerability. The CWE definition for the vulnerability is CWE-200. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. As an impact it is known to affect confidentiality. CVE summarizes:

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush. Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid(). Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues. However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate. And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away.

The advisory is available at git.kernel.org. This vulnerability was named CVE-2026-98715 since 09/25/2026. The exploitation appears to be easy. Local access is required to approach this attack. Additional levels of successful authentication are needed for exploitation. Technical details are known, but there is no available exploit. This vulnerability is assigned to T1592 by the MITRE ATT&CK project.

Upgrading to version 7.2.10 or 7.3-rc6 eliminates this vulnerability. Applying the patch fd873c3d1b5240e80365f09e758e8c96b88a7cdb/60d93c27859fb3ec5b5a689e24de303f166477d0 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.2.0
• 7.2.1
• 7.2.2
• 7.2.3
• 7.2.4
• 7.2.5
• 7.2.6
• 7.2.7
• 7.2.8
• 7.2.9
• 7.3-rc1
• 7.3-rc2
• 7.3-rc3
• 7.3-rc4
• 7.3-rc5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion