AMI AptioV UEFI BIOS (EDK II network stack, IPv6): An infinite loop when the firmware parses unknown options in an IPv6

Impact

An infinite loop when the firmware parses unknown options in an IPv6 Destination Options header. A single crafted packet hangs the node in pre-boot firmware - it never reaches the OS, never reports in, and cannot be recovered by a normal reboot because it will hang again on the next boot as long as the attacker keeps sending. On a GPU cluster this is a targeted capacity-denial tool: hold a set of nodes out of the scheduler indefinitely, and because the node is stuck below the OS your host-level monitoring shows nothing but silence.

Who can reach it

Network-reachable, unauthenticated, no interaction, low complexity - one packet during the node's network boot window. Anything that can put IPv6 traffic on the provisioning or boot segment qualifies, including a compromised neighbouring node.

What to do

BIOS update with the patched EDK II network package - firmware flash plus reboot per node, vendor-rebase-gated. The cheap and immediately available mitigation is the same as for the rest of the PixieFail family: disable network/PXE boot in BIOS where it is not needed, and where it is, put the provisioning network behind strict segmentation so no untrusted host can send packets into the boot window. BIOS setup change plus one reboot, versus a firmware flash campaign.

References