Insyde InsydeH2O (NvmExpressDxe, incorrect pointer checks): The NVMe driver's pointer validation is wrong, allowing

CVSS 8.2CVE-2022-29278Firmware, BMC & network fabricINSYDE-SA-2022061curated

Impact

The NVMe driver's pointer validation is wrong, allowing tampering with both SMRAM and OS memory. The driver reaches the NVMe data path - datasets, checkpoints, weights on a GPU node - and the bug hands an OS-level attacker ring -2 on top of it. Distinct from the DMA race in SA-2022055 and separately fixed; a node can carry one and not the other.

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.1 / 05.17.23 through 5.5 / 05.52.23. 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-29278 https://www.insyde.com/security-pledge/SA-2022061

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.