CVE-2021-4440

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/xen: Drop USERGS_SYSRET64 paravirt call<br /> <br /> commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.<br /> <br /> USERGS_SYSRET64 is used to return from a syscall via SYSRET, but<br /> a Xen PV guest will nevertheless use the IRET hypercall, as there<br /> is no sysret PV hypercall defined.<br /> <br /> So instead of testing all the prerequisites for doing a sysret and<br /> then mangling the stack for Xen PV again for doing an iret just use<br /> the iret exit from the beginning.<br /> <br /> This can easily be done via an ALTERNATIVE like it is done for the<br /> sysenter compat case already.<br /> <br /> It should be noted that this drops the optimization in Xen for not<br /> restoring a few registers when returning to user mode, but it seems<br /> as if the saved instructions in the kernel more than compensate for<br /> this drop (a kernel build in a Xen PV guest was slightly faster with<br /> this patch applied).<br /> <br /> While at it remove the stale sysret32 remnants.<br /> <br /> [ pawan: Brad Spengler and Salvatore Bonaccorso <br /> reported a problem with the 5.10 backport commit edc702b4a820<br /> ("x86/entry_64: Add VERW just before userspace transition").<br /> <br /> When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in<br /> syscall_return_via_sysret path as USERGS_SYSRET64 is runtime<br /> patched to:<br /> <br /> .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,<br /> 0x48, 0x0f, 0x07 }, // swapgs; sysretq<br /> <br /> which is missing CLEAR_CPU_BUFFERS. It turns out dropping<br /> USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS<br /> to be explicitly added to syscall_return_via_sysret path. Below<br /> is with CONFIG_PARAVIRT_XXL=y and this patch applied:<br /> <br /> syscall_return_via_sysret:<br /> ...<br /> : swapgs<br /> : xchg %ax,%ax<br /> : verw -0x1a2(%rip)