Insyde InsydeH2O (SdHostDriver and SdMmcDevice, untrusted pointer use): One advisory covering both SD layers: untrusted

Impact

One advisory covering both SD layers: untrusted pointers allow tampering with SMRAM and OS memory, giving ring -2 code execution. Easy to under-prioritise because SD/eMMC looks irrelevant on a GPU box, but the driver is compiled in and the SMI is reachable regardless of whether any SD media is present.

Who can reach it

Local admin/root on the host OS invoking the vulnerable software SMI with attacker-chosen pointers. On bare-metal GPU rental this is exactly the privilege the tenant already holds on their leased node.

What to do

Firmware flash from the server OEM, not from Insyde - the fixed Insyde kernel has to be rebased by Dell/HPE/Lenovo/Supermicro and re-qualified before it reaches you, which for this batch ran months behind Insyde's own release. One reboot per node, so schedule it against a GPU drain. Fixed in kernel 5.0 / 05.09.17 through 5.5 / 05.52.17. The compensating control that actually works here is the IOMMU, and Insyde says so in the advisory: enable VT-d/AMD-Vi with pre-boot DMA protection so the ACPI runtime buffer the handler reads is not reachable by an untrusted device. That is a BIOS setting, deployable fleet-wide without a flash, and it should be on already on any node that passes devices through to tenants. Patch the batch, not the CVE - Insyde filed one advisory per driver for the same defect, so fixing this one leaves every sibling handler reachable.

References