CVE-2021-47035

What it actually does

The vulnerability permitted Write-Only permission bits on second-level IOMMU paging entries for IOVA translation even though first-level entries always require the PRESENT bit (implying Read) and never support Write-Only; this created inconsistent permission semantics across paging levels.

Why it matters to the business

Organizations running affected Linux kernels on platforms using Intel VT-d IOMMU could experience unpredictable device DMA behavior or mapping failures when drivers or subsystems switch between first- and second-level translation, increasing operational risk for systems that rely on strict IOMMU isolation.

How an attack unfolds

An attacker with the ability to influence IOVA mappings would request a Write-Only permission configuration on a second-level entry; because the kernel previously honored this setting, the resulting mapping could grant write access without the read side-effect required by first-level semantics, allowing the attacker to observe or induce inconsistent DMA behavior that deviates from expected policy.

How to fix it

Update to a Linux kernel version that includes the referenced commit removing Write-Only permission support from second-level paging entries; rebuild and deploy the fixed kernel across all affected hosts.

How to confirm the fix worked

Confirm the running kernel contains the fix by inspecting the iommu/vt-d source for removal of WO permission handling, or verify that attempts to create Write-Only second-level mappings are rejected or converted to Read-Write.

Typical attack path

1. Identify a driver or subsystem that performs IOVA mapping via second-level translation
2. Craft or influence mapping requests to request Write-Only permissions
3. Trigger the mapping operation so the kernel installs a second-level entry with WO bits set
4. Observe or abuse the resulting DMA behavior that differs from first-level expectations

How to detect it

Review kernel build logs or source for the presence of the WO-permission removal commit; examine system logs for IOMMU mapping warnings or failures after upgrade; no runtime IOCs are known because the issue is a configuration inconsistency rather than an active exploit artifact.

What your security team should do

• Prioritize kernel upgrades on systems that actively use Intel VT-d IOMMU for device isolation
• Audit IOMMU-enabled workloads for any explicit Write-Only mapping assumptions
• Monitor vendor advisories for backported fixes in supported distribution kernels