// For flags

CVE-2024-35803

x86/efistub: Call mixed mode boot services on the firmware's stack

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. Normalmente, el código auxiliar de EFI llama a los servicios de arranque de EFI utilizando la pila que estaba activa cuando se ingresó el código auxiliar. Según la especificación UEFI, esta pila debe tener un tamaño mínimo de 128k; esto puede parecer grande, pero todo el procesamiento asíncrono y el manejo de eventos en EFI se ejecutan desde la misma pila, por lo que en la práctica se puede utilizar bastante espacio. En modo mixto, la situación es un poco diferente: el gestor de arranque llama al punto de entrada del código auxiliar EFI de 32 bits, que llama al punto de entrada de 32 bits del descompresor, donde se configura la pila de arranque, utilizando una asignación fija de 16k. Esta pila todavía está en uso cuando el código auxiliar EFI se inicia en modo de 64 bits, por lo que todas las llamadas al firmware EFI utilizarán la pila de arranque limitada del descompresor. Debido a la ubicación de la pila de arranque justo después del montón de arranque, cualquier desbordamiento de la pila pasa desapercibido. Sin embargo, la confirmación 5c4feadb0011983b ("x86/decompressor: Mover referencias de símbolos globales al código C") movió la definición del montón de arranque al código C, y ahora la pila de arranque se coloca justo en la base de BSS, donde cualquier desbordamiento dañará el final de la sección .data. Si bien sería posible solucionar este problema aumentando el tamaño de la pila de arranque, hacerlo afectaría a todos los sistemas x86, y los sistemas de modo mixto son una fracción pequeña (y cada vez menor) de la base instalada x86. En su lugar, registre el valor del puntero de la pila de firmware al ingresar desde el firmware de 32 bits y cambie a esta pila cada vez que se realice una llamada al servicio de arranque EFI.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-17 CVE Reserved
  • 2024-05-17 CVE Published
  • 2024-05-18 EPSS Updated
  • 2024-08-02 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.1.84
Search vendor "Linux" for product "Linux Kernel" and version " < 6.1.84"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.6.24
Search vendor "Linux" for product "Linux Kernel" and version " < 6.6.24"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.7.12
Search vendor "Linux" for product "Linux Kernel" and version " < 6.7.12"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.8.3
Search vendor "Linux" for product "Linux Kernel" and version " < 6.8.3"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
< 6.9
Search vendor "Linux" for product "Linux Kernel" and version " < 6.9"
en
Affected