LiveActive security incident?Get immediate response
CVE Record

CVE-2021-47035: iommu/vt-d: Remove WO permissions on second-level paging entries

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue concerns Intel VT-d IOMMU permission handling. The kernel allowed an inconsistent write-only setting for second-level I/O page tables, while first-level tables did not support that mode. Business impact is unclear from the sources because no CVSS, CWE, exploitation, or concrete attack outcome is provided.

Executive priority

Handle through normal kernel patch management, with higher priority for virtualization or hardware-isolation hosts. There is not enough evidence to justify emergency response, but kernel isolation issues should not be left indefinitely unpatched.

Technical view

The fix removes write-only permissions from VT-d second-level paging entries to align behavior with first-level IOVA translation, where PRESENT implies read permission and only read-only or read-write mappings are supported. The source describes consistency and correctness of IOMMU page-table permissions, not a demonstrated exploit path.

Likely exposure

Exposure is limited to Linux systems running affected kernel versions or downstream builds containing the vulnerable VT-d IOMMU code. Systems using Intel VT-d, IOMMU-backed device isolation, virtualization, or device passthrough deserve closer review. Distribution kernel backports may change apparent version exposure.

Exploitation context

The provided sources do not report active exploitation, public exploit code, or KEV listing. They also do not describe a practical attacker path. Treat this as a kernel correctness and isolation-hardening issue until vendor advisories provide stronger impact evidence.

Researcher notes

Key uncertainty is impact. The CVE text frames the change as removing an unsupported permission mode for consistency between first-level and second-level IOMMU translation. Additional research should focus on whether write-only second-level mappings could weaken DMA isolation in real configurations.

Mitigation direction

  • Update affected Linux kernels to vendor-supported builds containing the referenced stable fixes.
  • Check distribution advisories for backported fixes and exact package versions.
  • Prioritize hosts using Intel VT-d, IOMMU, virtualization, or device passthrough.
  • Avoid disabling IOMMU as a mitigation unless vendor guidance explicitly recommends it.

Validation and detection

  • Inventory kernel versions and distribution package release notes across Linux hosts.
  • Confirm whether Intel VT-d or IOMMU features are enabled on exposed systems.
  • Map running kernels to the fixed stable commits or vendor backport advisories.
  • Review virtualization and passthrough hosts before lower-risk general-purpose systems.
Prepared
Confidence
medium
Sources
7

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2021-47035 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
2ADP providers
6Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxb802d070a52a1565b47daaa808872cfbd4a17b01, b802d070a52a1565b47daaa808872cfbd4a17b01, b802d070a52a1565b47daaa808872cfbd4a17b01, b802d070a52a1565b47daaa808872cfbd4a17b01unaffected
LinuxLinux5.6, 0, 5.10.38, 5.11.21, 5.12.4, 5.13affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.