Gigabyte UEFI firmware (SMM, unchecked RBX pointer): An attacker-controlled register is used as an unchecked pointer

Impact

An attacker-controlled register is used as an unchecked pointer inside System Management Mode, giving arbitrary write in ring -2. SMM sits beneath the hypervisor and beneath the OS kernel, so code that lands here can disable Secure Boot, tamper with firmware, and persist through a full disk wipe and OS reinstall. On a rented GPU node this is the canonical 'tenant leaves something behind for the next tenant' primitive, and no host-based tooling can detect it.

Who can reach it

Local privileged code on the host - kernel-level or a driver, so a tenant with root on bare metal, or an attacker who already got kernel execution. Not remote, but on bare-metal rental the precondition is exactly what you sell.

What to do

UEFI/BIOS firmware update from Gigabyte, per board model, requiring a host reboot - which on GPU nodes means draining running training jobs. Gigabyte shipped fixed firmware; the practical problem is coverage, because affected models span consumer and server lines and not every SKU gets an image. There is no config workaround for an SMM callout. If you buy Gigabyte boards, make the firmware version part of your node-acceptance check, not a post-hoc audit.

References