Motherboards from ASRock and its subsidiaries ASRockRack and ASRockInd built on Intel 500-series chipsets

Impact

A DMA-capable PCIe device reads and writes system memory without restriction. On a GPU platform this is a direct hit on the assumption the whole tenant-isolation model rests on: IOMMU enforcement is what stops a device - or a tenant-controlled device - from reading arbitrary host memory, and it is what makes GPU passthrough to a VM safe. With it off, an attacker with a malicious or reprogrammed peripheral, or with control of a passed-through device, reads host kernel memory, extracts keys, and writes to memory to escalate. For any operator doing GPU passthrough or accepting tenant-supplied hardware, this invalidates the isolation guarantee. The IOMMU is not properly enabled, so the protection that is supposed to confine what a PCIe device can reach in system memory is simply not active.

Who can reach it

Physical access sufficient to attach a DMA-capable PCIe device - which includes Thunderbolt/USB4 ports, open PCIe slots, and any peripheral in a colocation or edge environment where the chassis is not under your exclusive control. Also relevant wherever a device is passed through to an untrusted guest, since the confinement that passthrough relies on is absent.

What to do

BIOS/UEFI update from ASRock, then verify - do not assume. After flashing, confirm the IOMMU is actually active at runtime: check for DMAR/IVRS tables and that the kernel reports IOMMU groups, rather than trusting a BIOS setting. ASRock and ASRockRack publish a security page, but it sits behind an Imperva challenge and returns unreadable content to automated clients, so advisory tracking has to be manual or via NVD and TWCERT. Config-only hardening in the meantime: enable IOMMU explicitly in BIOS and on the kernel command line, and disable unused Thunderbolt/PCIe hot-plug paths.

References