GPU VulnDB

Database/Firmware, BMC & network fabric

AMI MegaRAC SPx 13 (IPMI handler / host SPI flash path): The multi-tenant bare-metal nightmare

CVE-2023-34335Firmware, BMC & network fabricAMI-SA-2023005NVIDIA OSR reviewcurated

Impact

The multi-tenant bare-metal nightmare. An unauthenticated host - meaning code running on the server's own OS with no BMC credentials at all - can write the host's SPI flash through the BMC's IPMI handler, bypassing Secure Boot. A tenant who rents a bare-metal GPU node for an hour can leave a BIOS-resident implant behind that the next tenant inherits, and that no OS reimage, disk wipe or node rebuild will find. For anyone selling bare-metal GPU capacity this is a tenant-isolation break, not just a firmware bug.

Who can reach it

Requires code execution on the tenant/host OS (root or equivalent), then pivots inboard over the host-BMC interface - KCS/LPC or the in-band IPMI channel - to reach the BMC's flash write path. No BMC password, no management-network access, and no physical presence. The BMC VLAN being airtight does not help you here, because the attack comes from the host side.

What to do

BMC firmware flash to MegaRAC SPx_13.5 or later; out-of-band, per node, ODM-gated. Because the attack path is in-band, network segmentation buys you nothing - the only other lever is disabling the in-band host-to-BMC IPMI interface (KCS) in BIOS setup, which is a BIOS config change plus a reboot and will break in-band ipmitool, node health agents and most vendor management agents running on the host. If you sell bare-metal, treat this as a wipe-and-reflash-BIOS-between-tenants question rather than a patch question.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.