EDK II NetworkPkg (IScsiDxe, iSCSI login response processing): A hostile iSCSI target answers the firmware initiator

Impact

A hostile iSCSI target answers the firmware initiator with a malformed login response and gets out-of-bounds reads and writes in the pre-OS network stack. Realistic outcome per the upstream advisory is a hung or crashed boot rather than clean code execution, but for a fleet that boots from SAN this is an attacker holding nodes down from the storage side, and the write primitive is a corruption bug that has not been proven unexploitable so much as judged unlikely.

Who can reach it

Whoever controls or can impersonate the iSCSI target the node boots from - a compromised storage appliance, an attacker on the storage VLAN, or a rogue target answering discovery. Unauthenticated from the firmware's point of view, pre-OS.

What to do

OEM BIOS update; flash + reboot per node. Effective config workaround exists and is cheap: disable the UEFI iSCSI initiator on nodes that do not boot from SAN (a BIOS setting, no flash), and where you do boot from iSCSI, enable mutual CHAP so a rogue target cannot complete the login, and keep the storage network on its own VLAN.

References