CVE-2021-4440 in Linux
Summary
by MITRE • 06/25/2024
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Drop USERGS_SYSRET64 paravirt call
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but a Xen PV guest will nevertheless use the IRET hypercall, as there is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and then mangling the stack for Xen PV again for doing an iret just use the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the sysenter compat case already.
It should be noted that this drops the optimization in Xen for not restoring a few registers when returning to user mode, but it seems as if the saved instructions in the kernel more than compensate for this drop (a kernel build in a Xen PV guest was slightly faster with this patch applied).
While at it remove the stale sysret32 remnants.
[ pawan: Brad Spengler and Salvatore Bonaccorso
reported a problem with the 5.10 backport commit edc702b4a820 ("x86/entry_64: Add VERW just before userspace transition").
When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in syscall_return_via_sysret path as USERGS_SYSRET64 is runtime patched to:
.cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
0x48, 0x0f, 0x07 }, // swapgs; sysretq
which is missing CLEAR_CPU_BUFFERS. It turns out dropping USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS to be explicitly added to syscall_return_via_sysret path. Below is with CONFIG_PARAVIRT_XXL=y and this patch applied:
syscall_return_via_sysret: ... : swapgs : xchg %ax,%ax : verw -0x1a2(%rip) <------ : sysretq ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/06/2026
The vulnerability addressed in CVE-2021-4440 resides within the Linux kernel's x86 architecture implementation, specifically affecting paravirtualized Xen environments. This issue stems from the improper handling of system call returns through the USERGS_SYSRET64 paravirt call, which creates a discrepancy between the expected behavior for standard x86 systems and the actual requirements for Xen paravirtualized guests. The vulnerability manifests when the kernel attempts to optimize system call returns by using the SYSRET instruction, but fails to properly account for Xen's paravirtualization requirements that mandate the use of IRET hypercalls instead.
The technical flaw involves the kernel's attempt to perform a sysret operation in paravirtualized Xen environments where such an operation is not natively supported through the paravirtualization interface. The system maintains a complex code path where it tests prerequisites for sysret operations but then must manually manipulate the stack to perform an IRET operation, creating unnecessary complexity and potential security implications. This approach violates the principle of least privilege and introduces code paths that are both inefficient and potentially exploitable. The vulnerability is classified under CWE-254 as a "Weakness in Protection Mechanism" due to the improper handling of privileged operations and the inconsistent application of security measures across different execution contexts.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially compromise the security model of Xen paravirtualized environments. When CONFIG_PARAVIRT_XXL=y is enabled, the vulnerability becomes particularly problematic as it prevents the proper execution of CLEAR_CPU_BUFFERS operations, which are critical for mitigating side-channel attacks such as those described in the Spectre and Meltdown families. The patch resolves this by removing the USERGS_SYSRET64 paravirt call entirely and implementing a simpler ALTERNATIVE approach similar to that used for sysenter compat cases. This change ensures that all code paths consistently execute the necessary security mitigations, including the explicit addition of CLEAR_CPU_BUFFERS to the syscall_return_via_sysret path, thereby maintaining proper security boundaries and preventing potential exploitation through timing attacks or cache-based side-channel vulnerabilities.
The mitigation strategy involves eliminating the problematic optimization that was causing the inconsistency between different execution paths in paravirtualized environments. By removing the USERGS_SYSRET64 paravirt call and implementing a unified approach using ALTERNATIVE mechanisms, the kernel ensures that all system call returns through the same path execute the same security operations. This approach aligns with the ATT&CK framework's concept of privilege escalation through system call manipulation, as it prevents the creation of inconsistent security states that could be exploited by malicious actors. The patch also removes stale sysret32 remnants, which helps reduce the attack surface by eliminating unused code paths that could potentially be leveraged in advanced exploitation techniques. The performance implications of this change are minimal or positive, as demonstrated by the kernel build results showing slightly improved performance in Xen PV guests, while simultaneously providing better security guarantees. This change represents a fundamental improvement in the kernel's security architecture by ensuring consistent execution of security mitigations across all system call return paths in paravirtualized environments, thereby reducing the potential for exploitation through privilege escalation or side-channel attack vectors.