Insyde InsydeH2O (HddPassword shared buffer, DMA TOCTOU): Racy shared buffer in the ATA security driver

Impact

Racy shared buffer in the ATA security driver. What this one reaches is drive locking and unlock credentials, so a successful race yields ring -2 plus a foothold in the code holding drive secrets - which matters for any operator using ATA drive locks as part of the between-tenant wipe.

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. Insyde lists kernel 5.0 through 5.5 affected; take the per-kernel fixed version from the advisory. Do not rely on ATA HDD passwords as the at-rest control on unpatched nodes. 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. This is Insyde's second pass at the same defect class in a different set of buffers - a fleet that took the 2022 BIOS release is NOT covered for this batch, and OEM release notes rarely make that distinction clear. Verify by kernel version, not by 'we patched the Insyde DMA bugs'.

References