CVE-2024-35803

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