Insyde InsydeH2O (UsbCoreDxe, untrusted pointer use): UsbCoreDxe uses pointers it was handed without establishing they

Impact

UsbCoreDxe uses pointers it was handed without establishing they point outside SMRAM, so an OS-level caller gets SMM to tamper with either SMRAM or kernel memory. Ring -2 escalation from a driver that is resident on every node whether or not a USB device is plugged in. Not a DMA race - this one needs only host privilege, which makes it materially easier to exploit than the SA-2022042-057 set.

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.21, 5.1 / 05.17.21, 5.2 / 05.27.21, 5.3 / 05.36.21, 5.4 / 05.44.21, 5.5 / 05.52.21. Disabling USB legacy/emulation support in BIOS on headless nodes shrinks the reachable surface without a flash - confirm on your platform that it unloads the SMM module rather than only hiding the setup option. 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