CVE-2024-35803 is a vulnerability identified in the Linux kernel's handling of EFI (Extensible Firmware Interface) stub boot services on x86 architectures, specifically affecting mixed mode boot scenarios. The EFI stub is responsible for calling EFI boot services during system startup, using a stack that must comply with the UEFI specification requiring a minimum size of 128 KB. This large stack size is necessary because EFI asynchronous processing and event handling rely on it. However, in mixed mode booting—where a 32-bit EFI stub entry point is called by the bootloader, which then calls a 32-bit decompressor entry point that sets up a fixed 16 KB boot stack—the stack size is significantly smaller than required. This smaller stack remains in use when the EFI stub transitions to 64-bit mode, causing all calls back into the EFI firmware to use the limited 16 KB decompressor boot stack instead of the larger firmware stack. Historically, stack overruns were unnoticed due to the boot stack's placement after the boot heap, but a recent code change (commit 5c4feadb0011983b) moved the boot heap definition into C code, placing the boot stack at the base of the BSS segment. This change means any stack overruns now corrupt the end of the .data section, potentially causing memory corruption. Instead of increasing the boot stack size—which would impact all x86 systems despite mixed mode systems being a small and shrinking subset—the fix records the firmware stack pointer upon entering from the 32-bit firmware and switches to this firmware stack for all EFI boot service calls. This approach prevents stack overruns and memory corruption by ensuring the correct stack is used during EFI calls in mixed mode booting. No known exploits are reported in the wild, and the vulnerability affects specific Linux kernel versions identified by commit hashes.

For European organizations, the impact of CVE-2024-35803 primarily concerns systems running Linux kernels with mixed mode EFI boot configurations on x86 hardware. While mixed mode booting is relatively rare and shrinking in prevalence, organizations using specialized or legacy bootloaders that rely on this mode could experience system instability, memory corruption, or boot failures if unpatched. This could lead to denial of service conditions or potentially enable attackers with local access to cause unpredictable behavior during system startup. Given that the vulnerability affects the early boot process, exploitation would require physical or administrative access to the machine or the ability to modify bootloader behavior, limiting remote exploitation risk. However, critical infrastructure, data centers, or cloud providers in Europe that deploy Linux on diverse hardware platforms might face operational disruptions if affected systems are not updated. The vulnerability does not appear to directly expose confidentiality or integrity risks remotely but could impact availability and system reliability during boot. The lack of known exploits reduces immediate risk, but delayed patching could expose organizations to future targeted attacks or stability issues.

European organizations should take the following specific mitigation steps: 1) Identify Linux systems using EFI mixed mode booting on x86 platforms, focusing on those with custom or legacy bootloaders that invoke 32-bit EFI stubs. 2) Apply the Linux kernel patch that records and switches to the firmware stack pointer during EFI boot service calls, as described in the fix for CVE-2024-35803. This patch is critical to prevent stack overruns and memory corruption during boot. 3) Test kernel updates in controlled environments to ensure compatibility with existing bootloaders and hardware configurations, especially for specialized or embedded systems. 4) Review bootloader configurations and consider migrating away from mixed mode booting where feasible to reduce exposure. 5) Monitor vendor advisories and Linux kernel mailing lists for any updates or additional patches related to EFI boot services. 6) Implement physical security controls and restrict administrative access to prevent unauthorized modification of bootloaders or firmware. 7) Incorporate this vulnerability into vulnerability management and patching schedules to ensure timely remediation. These steps go beyond generic advice by focusing on the specific boot mode and stack handling nuances of this vulnerability.