CVE-2024-35803

In the Linux kernel, the following vulnerability has been resolved:
x86/efistub: Call mixed mode boot services on the firmware’s stack
Normally, the EFI stub calls into the EFI boot services using the stack
that was live when the stub was entered. According to the UEFI spec, this
stack needs to be at least 128k in size - this might seem large but all
asynchronous processing and event handling in EFI runs from the same stack
and so quite a lot of space may be used in practice. In mixed mode, the
situation is a bit different: the bootloader calls the 32-bit EFI stub
entry point, which calls the decompressor’s 32-bit entry point, where the
boot stack is set up, using a fixed allocation of 16k. This stack is still
in use when the EFI stub is started in 64-bit mode, and so all calls back
into the EFI firmware will be using the decompressor’s limited boot stack.
Due to the placement of the boot stack right after the boot heap, any stack
overruns have gone unnoticed. However, commit 5c4feadb0011983b
(“x86/decompressor: Move global symbol references to C code”) moved the
definition of the boot heap into C code, and now the boot stack is placed
right at the base of BSS, where any overruns will corrupt the end of the
.data section. While it would be possible to work around this by increasing
the size of the boot stack, doing so would affect all x86 systems, and
mixed mode systems are a tiny (and shrinking) fraction of the x86 installed
base. So instead, record the firmware stack pointer value when entering
from the 32-bit firmware, and switch to this stack every time a EFI boot
service call is made.