HIGH
iommu TLB Invalidation
CVE-2026-31735
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
KernelScan AI5.8MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: iommupt: Fix short gather if the unmap goes into a large mapping unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE. In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition. This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause. As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.
02KernelScan AI Analysis
Risk summary
Systems with IOMMU hardware could experience stale TLB entries when unmapping large page table entries, allowing a device to retain DMA access to memory that should have been unmapped. The vulnerability requires administrative privileges and specific memory layout conditions, making it difficult to trigger in practice.
Vulnerability analysis
The IOMMU unmap operation can unmap more memory than requested when the ending point lands within the middle of a large or contiguous IOPTE. The TLB invalidation (gather) only covered the requested range rather than the actual unmapped range, leaving stale TLB entries that could allow DMA access to unmapped memory. The fix ensures TLB invalidation covers the full unmapped range by using the actual unmapped size (unmap.unmapped) rather than the requested length. This is conceptually an operation on a mapping after it has been released from the page tables but not flushed from the TLB.
03Fix Versions
| Branch | Fixed in | Patch commit |
|---|---|---|
| 6.19 | 6.19.12 | 50ecd96a28f7 |
| mainline | 7.0 | ee6e69d03255 |