CVE-2022-2196 in Linux
Summary
by MITRE • 01/09/2023
A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn't need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/19/2025
The vulnerability described in CVE-2022-2196 represents a critical security flaw within the Linux kernel's KVM virtualization subsystem, specifically affecting the nVMX implementation that handles nested virtualization. This issue manifests as a speculative execution attack vector that exploits the improper handling of microcode features between different virtualization layers, creating a pathway for malicious actors to escalate privileges and execute arbitrary code on the host system. The vulnerability is classified as a regression, indicating that it emerged from a previous code change that introduced an unintended side effect in the kernel's virtualization handling mechanisms.
The technical root cause of this vulnerability lies in the improper management of eIBRS (enhanced Indirect Branch Restricted Speculation) support advertisement within the KVM hypervisor layer. When KVM (L0) advertises eIBRS support to the guest operating system (L1), it incorrectly assumes that L1 no longer requires retpolines or IBPB (Indirect Branch Prediction Barrier) mitigations. This assumption is fundamentally flawed because the L2 guest can still carry out Spectre v2 attacks against the L1 environment, creating a chain of speculative execution vulnerabilities that can be exploited by attackers with code execution privileges at the L2 level. The flaw specifically affects the nVMX implementation which handles nested virtualization scenarios where L1 and L2 guests operate simultaneously within the same host system.
The operational impact of this vulnerability is severe and potentially catastrophic for systems running virtualized environments. Attackers with code execution privileges at the L2 guest level can leverage this vulnerability to execute code on indirect branches of the host machine, effectively breaking the isolation boundaries that virtualization is designed to maintain. This type of attack allows for privilege escalation and can potentially lead to complete system compromise, as the attacker can access sensitive data and system resources that should remain isolated within the virtualized environment. The vulnerability is particularly dangerous because it operates at the microcode level and leverages speculative execution features that are designed to improve performance but can be exploited for malicious purposes.
The security implications extend beyond simple privilege escalation and align with the broader category of speculative execution side-channel attacks that have been extensively documented in various security frameworks including the ATT&CK framework under the technique of "Process Injection" and "Privilege Escalation" categories. This vulnerability demonstrates the complex nature of modern virtualization security where the hypervisor layer must properly manage feature advertisement and mitigation strategies across multiple virtualization levels. The issue is categorized under CWE-1163 which deals with improper handling of speculative execution vulnerabilities and represents a significant concern for organizations running Linux-based virtualized environments. Organizations should implement immediate mitigations by upgrading to kernel version 6.2 or applying the specific fix available in commit 2e7eab81425a, which corrects the improper eIBRS advertisement behavior and ensures proper isolation between virtualization layers. The fix addresses the fundamental flaw in how KVM handles microcode feature advertisement and restores the necessary protections that prevent L2 guests from exploiting L1's speculative execution mitigations.