CVE-2024-35803 Affecting kernel-64k-modules-partner package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL9-KERNEL64KMODULESPARTNER-6876011
- published18 May 2024
- disclosed17 May 2024
Introduced: 17 May 2024
CVE-2024-35803 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 kernel-64k-modules-partner.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-modules-partner package and not the kernel-64k-modules-partner package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
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.
References
- https://access.redhat.com/security/cve/CVE-2024-35803
- https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926
- https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc
- https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31
- https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02
- https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d