Insyde InsydeH2O (SdHostDriver and SdMmcDevice, untrusted pointer use): One advisory covering both SD layers: untrusted

CVSS 8.2CVE-2022-29279Firmware, BMC & network fabricINSYDE-SA-2022062curated

Impact

One advisory covering both SD layers: untrusted pointers allow tampering with SMRAM and OS memory, giving ring -2 code execution. Easy to under-prioritise because SD/eMMC looks irrelevant on a GPU box, but the driver is compiled in and the SMI is reachable regardless of whether any SD media is present.

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.17 through 5.5 / 05.52.17. 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

https://nvd.nist.gov/vuln/detail/CVE-2022-29279 https://www.insyde.com/security-pledge/SA-2022062

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.