From: Yu Zhang zhangyu1@linux.microsoft.com Sent: Thursday, July 10, 2025 4:11 PM
On Thu, Jul 10, 2025 at 03:02:07AM +0000, Tian, Kevin wrote:
From: Lu Baolu baolu.lu@linux.intel.com Sent: Wednesday, July 9, 2025 2:28 PM
The vmalloc() and vfree() functions manage virtually contiguous, but not necessarily physically contiguous, kernel memory regions. When vfree() unmaps such a region, it tears down the associated kernel page table entries and frees the physical pages.
In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. Architectures like x86 share static kernel address mappings across all user page tables, allowing the
I'd remove 'static'
IOMMU to access the kernel portion of these tables.
Modern IOMMUs often cache page table entries to optimize walk performance, even for intermediate page table levels. If kernel page table mappings are changed (e.g., by vfree()), but the IOMMU's internal caches retain stale entries, Use-After-Free (UAF) vulnerability condition arises. If these freed page table pages are reallocated for a different purpose, potentially by an attacker, the IOMMU could misinterpret the new data as valid page table entries. This allows the IOMMU to walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation.
this lacks of a background that currently the iommu driver is notified only for changes of user VA mappings, so the IOMMU's internal caches may retain stale entries for kernel VA.
To mitigate this, introduce a new iommu interface to flush IOMMU caches and fence pending page table walks when kernel page mappings are
updated.
This interface should be invoked from architecture-specific code that manages combined user and kernel page tables.
this also needs some words about the fact that new flushes are triggered not just for freeing page tables.
Thank you, Kevin. A question about the background of this issue:
My understanding of the attacking scenario is, a malicious user application could initiate DMAs to some vmalloced address, causing the paging structure cache being loaded and then possibly being used after that paging structure is freed(may be allocated to some other users later).
If that is the case, only when the paging structures are freed, do we need to do the flush. I mean, the IOTLB entries may not be loaded at all when the permission check failes. Did I miss anything? :)
It's about the paging structure cache instead of IOTLB.
You may look at the discussion in v1 for more background, especially the latest reply from Baolu about a detailed example:
https://lore.kernel.org/linux-iommu/2080aaea-0d6e-418e-8391-ddac9b39c109@lin...