Insyde InsydeH2O (HddPassword SMI input buffer, DMA TOCTOU): The HddPassword driver handles ATA security

Impact

The HddPassword driver handles ATA security - drive locking and unlock credentials. A DMA race here corrupts SMRAM and puts the attacker inside the code that holds drive-unlock secrets in memory, so the reachable prize is not just ring -2 but the credentials protecting the drive. Relevant to any fleet that leans on ATA drive locking as part of its between-tenant wipe story.

Who can reach it

An attacker able to drive DMA at host memory while the SMI handler is mid-flight - a malicious PCIe device, a peripheral running attacker-flashed firmware (NIC, GPU, NVMe), or a tenant with a passed-through device that is not behind a correctly configured IOMMU. Notably does NOT require host root, which is what separates this family from the ordinary SMM callout bugs.

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.2 / 05.27.23, 5.3 / 05.36.23, 5.4 / 05.44.23, 5.5 / 05.52.23. Do not treat ATA HDD passwords as the confidentiality control on unpatched nodes - prefer SED keys or software FDE with keys held off the node. 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