In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Force requesting ACS when tboot is enabled
Currently the conditions of requesting ACS in detect_intel_iommu()
don't include tboot, leading to a possible misconfiguration with ACS
disabled (e.g. due to user opts) while iommu is later forced on by
tboot_force_iommu().
Fix it by checking tboot in detect_intel_iommu().
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - detect_intel_iommu() runs at boot from pci_iommu_alloc() and, when tboot later forces VT-d on, skips pci_request_acs(); a local PCIe/Thunderbolt DMA device or VFIO-passthrough guest can then spoof requester IDs and issue peer-to-peer DMA. This is not a network-protocol path.
AC:L - On a tboot launch where intel_iommu=off, iommu=off, or default dmar_disabled skipped pci_request_acs(), ACS SV/RR/CR/UF/TB are never programmed; an attacker-controlled device can then deterministically perform P2P DMA or RID spoofing with no race or layout luck.
PR:N - A malicious PCIe/Thunderbolt device or a tenant with an assigned passthrough/SR-IOV function issues the DMA itself and needs no host account, capability, or init-namespace root, matching other VT-d isolation-bypass scores for unauthenticated devices.
UI:N - After the kernel boots with tboot-forced VT-d and ACS still disabled, the attacker’s device performs DMA on its own; no separate victim action such as mounting a filesystem or opening a file is required.
S:C - Missing ACS lets a device spoof requester IDs and send peer-to-peer TLPs that never reach the IOMMU, crossing the device/host DMA isolation boundary that tboot forces VT-d on to enforce (IOMMU/DMA boundary bypass is Scope Changed).
C:H - Without ACS source validation, request redirect, and translation blocking, a device can impersonate another requester ID or DMA to peer BARs, reading host or peer-device memory outside its IOMMU domain (arbitrary DMA disclosure).
I:H - The same ACS gap yields DMA writes into host or peer-device memory, including ATS without translation blocking on external/untrusted ports, providing an arbitrary write primitive that can corrupt kernel memory and hijack control flow.
A:H - Unchecked DMA writes and IOMMU-bypassing P2P traffic can corrupt kernel structures or provoke DMAR faults, oopses, and panics; any such host crash qualifies as High availability impact.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - detect_intel_iommu() runs at boot from pci_iommu_alloc() and, when tboot later forces VT-d on, skips pci_request_acs(); a local PCIe/Thunderbolt DMA device or VFIO-passthrough guest can then spoof requester IDs and issue peer-to-peer DMA. This is not a network-protocol path.
AC:L - On a tboot launch where intel_iommu=off, iommu=off, or default dmar_disabled skipped pci_request_acs(), ACS SV/RR/CR/UF/TB are never programmed; an attacker-controlled device can then deterministically perform P2P DMA or RID spoofing with no race or layout luck.
PR:N - A malicious PCIe/Thunderbolt device or a tenant with an assigned passthrough/SR-IOV function issues the DMA itself and needs no host account, capability, or init-namespace root, matching other VT-d isolation-bypass scores for unauthenticated devices.
UI:N - After the kernel boots with tboot-forced VT-d and ACS still disabled, the attacker’s device performs DMA on its own; no separate victim action such as mounting a filesystem or opening a file is required.
S:C - Missing ACS lets a device spoof requester IDs and send peer-to-peer TLPs that never reach the IOMMU, crossing the device/host DMA isolation boundary that tboot forces VT-d on to enforce (IOMMU/DMA boundary bypass is Scope Changed).
C:H - Without ACS source validation, request redirect, and translation blocking, a device can impersonate another requester ID or DMA to peer BARs, reading host or peer-device memory outside its IOMMU domain (arbitrary DMA disclosure).
I:H - The same ACS gap yields DMA writes into host or peer-device memory, including ATS without translation blocking on external/untrusted ports, providing an arbitrary write primitive that can corrupt kernel memory and hijack control flow.
A:H - Unchecked DMA writes and IOMMU-bypassing P2P traffic can corrupt kernel structures or provoke DMAR faults, oopses, and panics; any such host crash qualifies as High availability impact.
CVSS 3.1