VU#382314: what it is, what it is not, and the BIOS setting a firmware update may not turn on for you
In December 2025 CERT/CC published VU#382314. On certain motherboard models from ASUS, GIGABYTE, MSI and ASRock, the firmware reports that DMA protection is active while the IOMMU has not actually been enabled during early boot. Someone with physical access to the machine could use a DMA-capable PCIe device to read or modify system memory before the operating system's own protections load. It is not remotely exploitable, and there is nothing physically wrong with your board. On ASUS boards the fix is a firmware update plus a BIOS setting you have to enable yourself.
The IOMMU is the part of the platform that stops a device plugged into a PCIe slot from reading whatever memory it likes. Devices ask for memory addresses, and the IOMMU decides which ones they are allowed to touch. Until it is switched on, a DMA-capable card is trusted absolutely.
On the affected boards, the firmware sets the flag that says DMA protection is active without completing the work behind it. Anything downstream that checks that flag — including the operating system — is told the machine is protected during a window in which it is not. CERT/CC describes it as a discrepancy in which the firmware "asserts that DMA protections are active" but "fails to properly configure and enable the IOMMU during the early hand-off phase in the boot sequence."
Four CVE identifiers were issued, one per vendor implementation, because each vendor's firmware arrived at the same gap by a different route:
The flaw was disclosed by Nick Peterson and Mohamed Al-Sharifi of Riot Games, and coordinated through the Taiwanese CERT.
All four CVE records classify this as requiring physical access. Nobody reaches it over the internet. No web page, email attachment or downloaded program exploits it on its own. An attacker has to be at the machine, opening the case, and connecting a malicious PCIe device before the operating system starts.
That puts it in a specific bracket. It matters if a machine sits somewhere other people can reach it unattended — an office, a lab, a rental, a dock in a shared space — and it matters a great deal in managed fleets where a machine leaving your control is part of the threat model. For a desktop at home behind a locked front door, it is close to theoretical. Neither of those is a reason to leave it unfixed, but the first is a reason to prioritise it and the second is a reason not to panic about it.
This is not a recall. No board is defective, none is being replaced, and none that we cover has been withdrawn.
Each vendor's published scope is different, and the differences are not intuitive — a chipset family that appears on one vendor's list is absent from another's. These are the affected chipset families as recorded in the CVE records themselves:
| ASUS | Intel B460, B560, B660, B760, H410, H470, H510, H610, W480, W680, Z590, Z690 and Z790 series chipsets |
| GIGABYTE | Intel 600, 700 and 800 series; AMD 600 and 800 series; TRX50 |
| MSI | Intel 600 and 700 series |
| ASRock | Intel 500, 600, 700 and 800 series |
Every one of the four CVE records is scoped to certain motherboard models — not to every board built on a listed chipset. The model-by-model lists are published by each vendor on its own security page, linked below, and those pages are the only place to settle the question for a particular board. We do not publish a per-board status here, because we cannot verify it for every model, and a list that is wrong is worse than no list at all.
Three steps, in order.
That third step is documented by ASUS. The advisories published for GIGABYTE, MSI and ASRock through the Taiwanese CERT say only to update to the latest firmware, and do not describe a manual setting. If your board is one of those and its BIOS offers an IOMMU or DMA protection option, it is worth reading your board's release notes to see whether the update enables it for you.
CERT/CC's note records statements from ASUS and GIGABYTE. At its last revision, on 22 December 2025, it recorded no statement received from either MSI or ASRock. That is not the same as saying those vendors have shipped nothing — it means they had not filed a position with CERT/CC at that point.
That is the position as CERT/CC recorded it in December 2025. We could not read any of the four vendors' own advisory listings to check whether it has changed since — two refused our request outright and two returned an empty list — so we are not telling you that a fix exists for your board, and not telling you that one does not. Your vendor's own page below is the authority, and it is worth checking even if the note above says your vendor stayed quiet.
The CVE identifiers, dates, affected chipset lists and technical description on this page come from the CERT/CC note and the published CVE records, all linked below and all read in full. Nothing on this page is a test result: no board was flashed, and no exploit was reproduced. We could not read the four vendors' own advisory listings, so this page attributes each vendor's position to CERT/CC's record of it rather than to the vendor's current page, and it does not reproduce any vendor's per-model list.
Published 21 August 2026. Vendor positions last checked against CERT/CC on 21 August 2026.