CVE-2026-89448 et la leçon : l’isolation DMA est une configuration, pas une case à cocher

Ask most enthusiasts how a PC defends itself against rogue PCIe devices and you will hear one word: IOMMU. Turn on VT-d or AMD-Vi, the story goes, and devices can only touch the memory they were given. A Linux kernel vulnerability published in September 2026 is a good reminder that the real picture has more parts. CVE-2026-89448 describes a case where the IOMMU could be forced on while a separate PCIe isolation feature it relies on was never requested. The IOMMU was on, but isolation was incomplete.

This article looks at the bug from a defender’s and educator’s point of view: what was fixed, who is realistically affected, and what it says about how DMA protection should be verified. It contains no exploitation detail, and none is needed to learn from it.

What was fixed

The CVE record, published on September 11, 2026, covers a Linux kernel change titled “iommu/vt-d: Force requesting ACS when tboot is enabled.” The patch appeared on the Linux kernel mailing list in early August as part of a 20-patch series of IOMMU changes posted by Lu Baolu, with Kevin Tian credited as author, and was marked for backporting to stable kernels.

According to the patch description, the kernel’s Intel IOMMU detection code decided whether to request PCIe Access Control Services (ACS) without considering tboot, the open-source pre-kernel module used to launch Linux with Intel Trusted Execution Technology. That left room for a mismatch: ACS could end up not requested (for example, because of user boot options), while tboot later forced the IOMMU on anyway. The fix adds a tboot check to the detection logic so that when tboot forces the IOMMU, ACS is requested too.

OpenCVE’s record lists the issue as affecting kernels back to 2.6.33 and shows fixed releases in several maintained branches, including 6.6.157, 6.12.109, 6.18.50, and 7.2.4, with 7.3-rc1 also unaffected.

Why ACS matters

To see why this is more than a bookkeeping bug, it helps to picture the PCIe topology. Devices often sit behind switches or root ports that can route traffic between each other directly. ACS is the PCIe feature that controls that peer-to-peer routing. With the right ACS settings, a switch sends device-to-device transactions upstream so the IOMMU can check them. Without them, some transactions between peers may never reach the IOMMU.

This is also why Linux groups devices into IOMMU groups. When the kernel cannot be sure that two devices are isolated from each other, it treats them as one unit for isolation purposes. ACS is one of the signals that lets the kernel split them apart safely.

Put simply, the IOMMU controls what a device can do to host memory. ACS helps make sure devices cannot quietly go around the IOMMU by talking to each other. A configuration with the first and not the second is weaker than it looks, and CVE-2026-89448 is a case where the kernel could arrive at that state on its own.

Severity, in proportion

Scores for this CVE vary, which is a good lesson in itself. The OpenCVE record shows a CVSS 3.1 base score of 9.3 (critical) with a local attack vector, while its change history also shows a separate “moderate” threat severity rating. The same record lists an EPSS exploitation probability below 1 percent and notes that the issue is not in CISA’s Known Exploited Vulnerabilities catalog.

The practical scope is narrow. The condition involves systems booted through tboot with Intel TXT, which is mostly found in specific enterprise, government, and measured-launch deployments rather than typical gaming desktops. It also depends on ACS having been disabled or not requested through other settings. Treat it as a real bug that deserves a patch, not as a reason to panic about every Linux machine with an Intel CPU.

For defenders, the useful part is not the score. It is the category of failure.

The category: silent configuration drift

The most instructive IOMMU problems are rarely dramatic bypasses. They tend to be cases where the pieces are present but do not add up:

• The IOMMU is enabled, but some devices are not remapped. On Windows, for example, Microsoft’s documentation explains that Kernel DMA Protection blocks external peripherals whose drivers do not support DMA remapping until a user signs in, and lets administrators adjust that policy. The protection depends on driver behavior and policy, not only on a firmware toggle.
• The OS is protected, but the boot phase is not. Microsoft states that Kernel DMA Protection applies only after the OS loads, and that protecting ports during boot is the firmware’s job.
• The IOMMU is on, but peer-to-peer isolation is off. That is the shape of CVE-2026-89448.
• Settings interact in unexpected ways. Boot parameters, measured-launch tooling, and firmware options can each look correct alone and still combine into a weaker state.

This is why hardware security reviews should verify outcomes, not just settings. “VT-d: Enabled” in a BIOS menu is a starting point, not a conclusion.

A defender’s checklist

For administrators, researchers, and educators running Linux systems where DMA isolation matters, a sensible response looks like this:

1. Patch. Move to a kernel that includes the fix. Distribution kernels often backport changes without changing the upstream version number, so check your vendor’s security tracker rather than relying on version strings alone.
2. Inventory measured-launch systems. Find out whether any machines boot through tboot. If you are unsure, that is worth answering in its own right.
3. Review boot parameters. Kernel command-line options that change IOMMU or ACS behavior are sometimes added for convenience, such as device passthrough experiments, and then forgotten. Document why each exists.
4. Check IOMMU groups. Unexpectedly large groups can be a sign that isolation is weaker than intended. Changes after a kernel update deserve a look.
5. Keep firmware current. DMA protection depends on firmware tables and settings as much as on the kernel.
6. Separate lab and production. Machines used for PCIe or DMA experiments should be isolated from sensitive networks and data, with their configuration tracked like any other test asset.

Why this matters to the DMA research community

Legitimate DMA hardware exists in large part because defenders need to test claims like “the IOMMU protects us.” Bugs such as CVE-2026-89448 show why those tests are valuable. A lab that can confirm, on owned hardware, whether a given configuration really isolates devices is doing the work that turns documentation into assurance. The responsible version of that work stays inside controlled environments, reports findings to kernel maintainers or vendors through their normal channels, and publishes lessons rather than weaponized tooling.

The same thinking applies to game integrity and platform security. Anti-cheat teams, OS vendors, and hardware makers increasingly lean on IOMMU-backed protections as part of a layered defense against DMA as a threat class. Those protections are only as strong as their weakest configuration interaction, and finding those interactions before attackers do is the job of the research community.

The takeaway

CVE-2026-89448 is a small patch with a big lesson. The Linux fix is a few lines of logic that make ACS requests follow the same rules as tboot’s forced IOMMU. The lesson is that DMA protection is a system property built from firmware, kernel logic, device capabilities, and boot configuration together. Patch the kernel, check what is actually enforced, and treat every “enabled” checkbox as a claim to verify.