CVE-2026-89448

What it actually does

On Intel VT-d systems, detect_intel_iommu() did not treat tboot as a reason to request PCIe Access Control Services (ACS). tboot can later force the IOMMU on via tboot_force_iommu() while ACS remains off (including when disabled by user options). Without ACS, peer-to-peer PCIe transactions can bypass IOMMU DMA remapping, so device DMA is not confined as the IOMMU/TXT model requires. That isolation failure can yield local privilege escalation and host-wide compromise of confidentiality, integrity, and availability (CVSS 9.3, scope changed).

Why it matters to the business

Hosts that depend on Intel TXT/tboot and VT-d for trusted launch and DMA protection may run with weaker device isolation than operators expect, creating a path from a local attacker or a malicious/compromised PCIe device to full machine takeover and possible impact beyond a single guest or process. Linux kernel exposure is broad wherever Intel IOMMU and tboot are used. The issue is not in CISA KEV, is not associated with ransomware, has no public exploit maturity, and EPSS remains very low and flat (~0.0014 over 30 days). Thirty-one days after publication, urgency is highest for TXT/measured-launch and multi-tenant IOMMU fleets rather than untargeted mass exploitation.

How an attack unfolds

An attacker targets a Linux system where tboot/TXT is enabled so the Intel IOMMU is forced on, but ACS was never requested and may have been turned off by configuration. They obtain local code execution or control of a DMA-capable PCIe function. Because ACS is absent, peer-to-peer PCIe traffic can go around DMA remapping. The attacker then uses unconstrained DMA to read or write privileged memory, break TXT/IOMMU guarantees, and escalate to kernel, hypervisor, or other security domains. No named threat actors or campaigns are tied to this CVE, and no public exploit is known.

How to fix it

Install a Linux kernel that includes the iommu/vt-d fix forcing ACS to be requested when tboot is enabled in detect_intel_iommu(). Use your distribution’s patched kernel packages; exact fixed versions were not listed in the source data, so confirm via vendor advisories and changelogs. Do not disable ACS on tboot/TXT systems (avoid ACS-override style boot options). Keep VT-d/IOMMU enabled as tboot requires. Until patched, restrict untrusted PCIe and Thunderbolt devices and avoid assigning untrusted devices into IOMMU groups on those hosts.

How to confirm the fix worked

Verify the running kernel changelog or source contains the tboot ACS check in detect_intel_iommu(). After reboot, confirm DMAR/IOMMU is active, ACS is enabled on relevant PCIe downstream ports (for example lspci ACS capability output), and tboot-forced IOMMU did not leave ACS off. Inspect kernel command line and firmware settings for ACS-disabling options. Re-test on Intel TXT/tboot hardware, not only on hosts without tboot.

Typical attack path

1. Locate a Linux host using Intel VT-d with tboot/TXT enabled and ACS not requested (for example ACS disabled by boot or user options).
2. Gain local execution or influence over a DMA-capable PCIe device on that host.
3. Rely on the IOMMU being forced on without ACS so peer-to-peer DMA is not properly constrained.
4. Use unconstrained DMA to access memory outside the intended isolation boundary.
5. Escalate privileges or compromise kernel, hypervisor, or other tenants, then persist or steal data.

How to detect it

No in-the-wild campaigns or unique malware artifacts are published for this issue. Hunt for exposure and DMA-style misuse, not a signatured payload: boot logs for DMAR/IOMMU and ACS, tboot/TXT launch records, and command lines that disable ACS; unexpected PCIe or Thunderbolt devices; sudden vfio/device-passthrough changes; and unexplained kernel memory corruption after new devices appear. Compare running kernel versions to patched builds. Absence of those clues does not prove the bug was unused, because successful DMA abuse may leave little in conventional logs.

What your security team should do

• Patch Intel TXT/tboot Linux hosts that use VT-d first; treat those as high severity even though this CVE is not KEV.
• Inventory tboot, intel_iommu, and ACS-related boot parameters; flag systems that disable ACS while IOMMU/tboot is in use.
• Until patched, block or tightly control untrusted PCIe/Thunderbolt hotplug and device assignment on those hosts.
• Track distribution kernel advisories for the iommu/vt-d ACS/tboot fix; there is no CISA due date.
• Given low, unchanged EPSS and no known exploits, avoid organization-wide emergency change outside TXT/high-assurance and multi-tenant IOMMU fleets, but do not delay those environments.