Various Issues Due To Exposed SMI Handler in AmdPspP2CmboxV2. The first issue can be leveraged to bypass the protections that have been put in place by previous UEFI phases to prevent direct access to the SPI flash. The second issue can be used to both leak and corrupt SMM memory, thus potentially leading code execution in SMM

Various Issues Due To Exposed SMI Handler in AmdPspP2CmboxV2. The first issue can be leveraged to bypass the protections that have been put in place by previous UEFI phases to prevent direct access to the SPI flash. The second issue can be used to both leak and corrupt SMM memory thus potentially leading code execution in SMM

In the Linux kernel, the following vulnerability has been resolved: drm: Check output polling initialized before disabling In drm_kms_helper_poll_disable() check if output polling support is initialized before disabling polling. If not flag this as a warning. Additionally in drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() calls, that re the callers of these functions, avoid invoking them if polling is not initialized. For drivers like hyperv-drm, that do not initialize connector polling, if suspend is called without this check, it leads to suspend failure with following stack [ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug) [ 770.948823] ------------[ cut here ]------------ [ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230 [ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner ud…

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 5…

Improper input validation in PfrSmiUpdateFw driver in UEFI firmware for some Intel(R) Server M50FCP Family products may allow a privileged user to enable escalation of privilege via local access.

Improper buffer restrictions in PlatformPfrDxe driver in UEFI firmware for some Intel(R) Server D50FCP Family products may allow a privileged user to enable escalation of privilege via local access.

Improper input validation in UserAuthenticationSmm driver in UEFI firmware for some Intel(R) Server D50DNP Family products may allow a privileged user to enable escalation of privilege via local access.

Improper input validation in PprRequestLog module in UEFI firmware for some Intel(R) Server D50DNP Family products may allow a privileged user to enable escalation of privilege via local access.

Improper input validation in PlatformVariableInitDxe driver in UEFI firmware for some Intel(R) Server D50DNP Family products may allow a privileged user to enable escalation of privilege via local access.

Improper input validation of EpsdSrMgmtConfig in UEFI firmware for some Intel(R) Server Board S2600BP products may allow a privileged user to potentially enable denial of service via local access.