Insyde InsydeH2O (AhciBusDxe, untrusted SMI inputs): SMI functions in the AHCI/SATA driver consume untrusted inputs

Impact

SMI functions in the AHCI/SATA driver consume untrusted inputs and corrupt SMRAM. Straight privilege escalation to ring -2 for anyone with host root - firmware persistence that survives OS reinstall, plus control over the SATA path the node boots from.

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.18 through 5.5 / 05.52.18. 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