Insyde InsydeH2O (PnpSmm function 0x52, SMBIOS write address manipulation): PnpSmm function 0x52 takes an address

Impact

PnpSmm function 0x52 takes an address and a size for data to write into the SMBIOS table and does not constrain where that address points. Malware supplies its own address and overwrites SMRAM or OS kernel memory - an arbitrary write primitive handed over by a documented firmware function, no race and no exotic hardware needed. The cleanest escalation in the batch.

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.41, 5.1 / 05.17.43, 5.2 / 05.27.30, 5.3 / 05.36.30, 5.4 / 05.44.30, 5.5 / 05.52.30. 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