Insyde InsydeH2O (IhisiSmm / IhisiDxe command buffer): One representative of a family of roughly a dozen Insyde

Impact

One representative of a family of roughly a dozen Insyde advisories covering the same defect across different drivers: the SMI handler validates its parameters in a buffer that sits outside SMRAM, then uses them - and a DMA-capable device can rewrite that buffer in between. The result is SMRAM corruption and privilege escalation to ring -2 driven from a peripheral rather than from the CPU. In a GPU chassis the DMA-capable devices are GPUs, NICs and NVMe drives, several of which run tenant-flashable firmware, so this is not a theoretical adversary.

Who can reach it

An attacker with control of a DMA-capable device on the node - a compromised NIC or GPU firmware, a malicious PCIe device, or a tenant who can drive DMA from a passed-through device - racing the SMI handler. Does not require host root, which is what makes the family interesting.

What to do

OEM BIOS update on the fixed Insyde kernel. Firmware flash, reboot per node. The real compensating control here is the IOMMU: enable VT-d/AMD-Vi and DMA protection (including pre-boot DMA protection where the platform supports it) so untrusted devices cannot reach arbitrary host memory. That is a config change and should be standard on any multi-tenant GPU node regardless of this CVE. Note the sibling advisories SA-2023001 through SA-2023015 cover the same bug in PnpSmm, FwBlockServiceSmm, HddPassword, AhciBusDxe, IdeBusDxe, NvmExpressDxe, SdHostDriver, SdMmcDevice, StorageSecurityCommandDxe, VariableRuntimeDxe and FvbServicesRuntimeDxe - patching one does not patch the rest.

References