AMD PSP1 Configuration Block (APCB) parsing: An out-of-bounds memory write while the platform processes the AMD PSP1

Impact

An out-of-bounds memory write while the platform processes the AMD PSP1 Configuration Block. Reaching it requires the ability to modify and re-sign the BIOS image, which is a high bar - but the payoff is memory corruption inside the secure processor's configuration path, i.e. control of the root of trust with a signature that validates.

Who can reach it

Local, and requires both BIOS image modification and the ability to sign the result. That combination points at a signing-key compromise or an insider in the firmware build pipeline rather than a runtime attacker.

What to do

Fixed in AMD reference firmware (AGESA / PSP / SEV firmware) and delivered only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo and the ODMs each rebuild and requalify AMD's AGESA drop before shipping. **Expect one to six months of OEM lag**, and on end-of-support platforms expect nothing. Applying it is a drain plus full power cycle, not a driver reload. Verify by reading back the PSP/SMU firmware version afterwards rather than trusting the BIOS version string. The signing prerequisite means your firmware supply chain is the real control here - who can sign a BIOS for your fleet, and how is that key held?

References