GPU VulnDB

Database/Control plane, storage & DevOps

SPI flash configuration (flash descriptor / protected range registers) across multiple Intel platforms

CVE-2017-5703Control plane, storage & DevOpsINTEL-SA-00087curated

Impact

Misconfiguration of SPI flash protection lets a local attacker change how the SPI flash behaves, up to and including bricking the node. In a GPU fleet the operator-facing outcome is a hard denial of service that no reimage fixes: the node will not POST and needs a physical flash recovery (external programmer or OEM RMA), so it is an unplanned rack visit and a node out of revenue for days. Where write protection is incomplete rather than merely unstable, the same weakness is the standard route to a persistent BIOS implant that survives every reimage and every tenant handoff.

Who can reach it

Local privileged code on the host writing to the SPI controller's configuration and protected-range registers. Reachable by any tenant with root on a bare-metal node.

What to do

BIOS/platform firmware update from the OEM that sets the flash descriptor and protected-range/BIOS-lock registers correctly - HPE, Dell, Supermicro and Lenovo all shipped these; reboot and drain required. Independently of the patch, audit the flash-protection state on your actual fleet (BIOSWE/BLE/SMM_BWP/PRx and descriptor lock) with a tool like CHIPSEC as part of node acceptance and node reclaim, because these bits are set by the OEM's BIOS build and vary by SKU and by BIOS version even within one OEM.

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.