CVE-2022-48727 in Linux
Summary
by MITRE • 06/20/2024
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Avoid consuming a stale esr value when SError occur
When any exception other than an IRQ occurs, the CPU updates the ESR_EL2 register with the exception syndrome. An SError may also become pending, and will be synchronised by KVM. KVM notes the exception type, and whether an SError was synchronised in exit_code.
When an exception other than an IRQ occurs, fixup_guest_exit() updates vcpu->arch.fault.esr_el2 from the hardware register. When an SError was synchronised, the vcpu esr value is used to determine if the exception was due to an HVC. If so, ELR_EL2 is moved back one instruction. This is so that KVM can process the SError first, and re-execute the HVC if the guest survives the SError.
But if an IRQ synchronises an SError, the vcpu's esr value is stale. If the previous non-IRQ exception was an HVC, KVM will corrupt ELR_EL2, causing an unrelated guest instruction to be executed twice.
Check ARM_EXCEPTION_CODE() before messing with ELR_EL2, IRQs don't update this register so don't need to check.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/01/2025
The vulnerability described in CVE-2022-48727 affects the Linux kernel's KVM implementation on arm64 architecture, specifically addressing a critical issue in exception handling mechanisms. This flaw resides within the virtualization subsystem where the kernel manages virtual machine execution through the Kernel-based Virtual Machine framework. The vulnerability manifests when handling synchronous exceptions, particularly when SError conditions occur during virtual machine execution, creating a scenario where stale register values can lead to unpredictable behavior in guest operating systems.
The technical root cause involves the improper handling of the ESR_EL2 (Exception Syndrome Register) within the fixup_guest_exit() function during KVM guest exit processing. When exceptions occur in the arm64 architecture, the CPU automatically updates ESR_EL2 with syndrome information about the exception type and context. However, the KVM implementation fails to properly distinguish between different types of exception handling scenarios. The vulnerability specifically occurs when an IRQ (Interrupt Request) synchronizes an SError condition, causing the vcpu->arch.fault.esr_el2 value to become stale and outdated.
During normal exception processing, KVM examines the exception type and SError synchronization status stored in exit_code to determine appropriate handling. When an SError is synchronized, KVM uses the vcpu esr value to identify if the original exception was due to an HVC (Hypervisor Call) instruction. This identification is crucial for proper instruction pointer management, where ELR_EL2 (Exception Link Register) needs to be adjusted to re-execute the HVC instruction after processing the SError. The system attempts to move ELR_EL2 back by one instruction to ensure proper re-execution of the guest instruction that triggered the exception.
However, when an IRQ synchronizes an SError, the vcpu esr value retains information from a previous non-IRQ exception, creating a stale reference that no longer accurately represents the current exception context. This stale value leads to incorrect determination of whether the original exception was an HVC, resulting in improper ELR_EL2 adjustment. The consequence is that an unrelated guest instruction gets executed twice, fundamentally corrupting the execution flow and potentially leading to arbitrary code execution or system instability. This issue directly relates to CWE-122, which addresses improper restriction of operations within a recognized security boundary, and specifically targets the ARM architecture's exception handling mechanisms.
The operational impact of this vulnerability extends beyond simple execution corruption, potentially allowing malicious actors to exploit the instruction pointer manipulation for privilege escalation or denial of service attacks. Attackers could craft specific sequences of exceptions and interrupts to force the kernel into executing unintended guest instructions, creating opportunities for code injection or system compromise. The vulnerability's severity is amplified by its location within the hypervisor layer, where it can affect all virtual machines running on the affected system, making it particularly dangerous in multi-tenant environments. According to ATT&CK framework, this vulnerability maps to T1059.007 for command and scripting interpreter, as well as T1499.004 for network disruption, through potential exploitation paths that could leverage the instruction corruption for further attack vectors.
Mitigation strategies should focus on implementing proper exception type checking before modifying critical registers like ELR_EL2. The fix requires checking ARM_EXCEPTION_CODE() before performing any ELR_EL2 adjustments, ensuring that only non-IRQ exceptions trigger the ESR_EL2 value evaluation and instruction pointer correction. This approach prevents the corruption of instruction pointers when IRQs synchronize SError conditions. System administrators should prioritize applying the kernel patches that address this specific vulnerability, particularly in environments running virtualized workloads where KVM is utilized. Organizations should also implement monitoring for unusual exception handling patterns and maintain updated virtualization security practices to prevent exploitation attempts that may leverage this type of hypervisor-level vulnerability.