Phoenix SecureCore (TPM configuration / SetupUtility, unsafe UEFI variable handling in SMM): A buffer overflow in how

Impact

A buffer overflow in how SecureCore handles a TPM-configuration UEFI variable inside SMM. An attacker overwrites adjacent SMM memory, escalates to ring -2, and installs a bootkit that persists through OS reinstall and disk replacement. Eclypsium's point in naming it was breadth: the same SecureCore code ships across Alder Lake, Coffee Lake, Comet Lake, Ice Lake, Jasper Lake, Kaby Lake, Meteor Lake, Raptor Lake, Rocket Lake and Tiger Lake, so hundreds of PC and server models from multiple OEMs inherit it from one IBV defect. That inheritance pattern is the real lesson for a fleet operator - your firmware exposure is set by an IBV you have no contract with.

Who can reach it

Local admin/root on the host OS writing the vulnerable UEFI variable, then triggering the SMM path. NVD scores it AV:L/PR:L; Phoenix's own CNA scoring assumes higher privilege and higher complexity, which is why the two scores differ (7.8 NVD vs 7.5 Phoenix).

What to do

BIOS update from your server or system OEM built on the fixed Phoenix SecureCore version - Phoenix lists per-platform fixed versions and OEMs shipped on their own schedules through mid-to-late 2024. Firmware flash plus one reboot per node. No config workaround: the TPM configuration variable is part of normal platform setup and cannot be disabled. Audit by silicon generation rather than by this CVE alone - Phoenix filed the Gemini Lake instance of the same defect as a separate advisory (CVE-2024-1598, fixed in SecureCore for Gemini Lake 4.1.0.567), and OEM release notes commonly cite only one of the two, so a fleet can be patched for the headline case and still exposed on Gemini Lake-based management, edge or storage nodes in the same racks. Where a node cannot be patched promptly, restrict who gets administrative access to the host OS, since that is the entry condition.

References