AMI AptioV UEFI BIOS (EDK II network stack, DHCPv6 client): Buffer overflow in the firmware's DHCPv6 client, triggered

Impact

Buffer overflow in the firmware's DHCPv6 client, triggered by an over-long server ID option. The attacker gets code execution in the pre-boot firmware environment - before the OS, before Secure Boot has finished mattering, with full access to the platform. For a GPU fleet the sharp edge is network provisioning: PXE and HTTP boot are how most clusters bring nodes up, and the firmware talks IPv6 DHCP during that window whether or not you intended to use IPv6. An attacker on the provisioning VLAN answers first and owns the node before it has an operating system.

Who can reach it

Adjacent network, unauthenticated, no interaction - the attacker just needs to be on the same segment as the booting node and respond to its DHCPv6 solicitation faster than your real server. Every node reboot is a fresh opportunity, so on a fleet that autoscales or recovers nodes constantly the window is effectively always open. Note that IPv6 is exercised even in IPv4-only deployments because the firmware stack solicits regardless.

What to do

BIOS update carrying the patched EDK II network package - firmware flash plus host reboot per node, gated on your server vendor rebasing AMI's AptioV build; AMI's advisory names 'AptioV' generically rather than a BKC version, so confirm the specific BIOS release with your OEM. There is a real config-only mitigation and you should apply it regardless: disable PXE and network boot in BIOS on nodes that do not need it, and where you do need it, isolate the provisioning VLAN so nothing untrusted can answer DHCP on it. That is a BIOS setup change plus one reboot per node, far cheaper than the flash.

References