On Sun, Oct 26, 2025 at 03:55:04PM +0800, Shuai Xue wrote:
在 2025/10/22 20:50, Jason Gunthorpe 写道:
On Mon, Oct 13, 2025 at 06:26:11PM +0300, Leon Romanovsky wrote:
From: Leon Romanovsky leonro@nvidia.com
Add support for exporting PCI device MMIO regions through dma-buf, enabling safe sharing of non-struct page memory with controlled lifetime management. This allows RDMA and other subsystems to import dma-buf FDs and build them into memory regions for PCI P2P operations.
The implementation provides a revocable attachment mechanism using dma-buf move operations. MMIO regions are normally pinned as BARs don't change physical addresses, but access is revoked when the VFIO device is closed or a PCI reset is issued. This ensures kernel self-defense against potentially hostile userspace.
Let's enhance this:
Currently VFIO can take MMIO regions from the device's BAR and map them into a PFNMAP VMA with special PTEs. This mapping type ensures the memory cannot be used with things like pin_user_pages(), hmm, and so on. In practice only the user process CPU and KVM can safely make use of these VMA. When VFIO shuts down these VMAs are cleaned by unmap_mapping_range() to prevent any UAF of the MMIO beyond driver unbind.
However, VFIO type 1 has an insecure behavior where it uses follow_pfnmap_*() to fish a MMIO PFN out of a VMA and program it back into the IOMMU. This has a long history of enabling P2P DMA inside VMs, but has serious lifetime problems by allowing a UAF of the MMIO after the VFIO driver has been unbound.
Hi, Jason,
Can you elaborate on this more?
From my understanding of the VFIO type 1 implementation:
- When a device is opened through VFIO type 1, it increments the device->refcount
- During unbind, the driver waits for this refcount to drop to zero via wait_for_completion(&device->comp)
- This should prevent the unbind() from completing while the device is still in use
Given this refcount mechanism, I do not figure out how the UAF can occur.
A second vfio device can be opened and then use follow_pfnmap_*() to read the first vfio device's PTEs. There is no relationship betweent the first and second VFIO devices, so once the first is unbound it sails through the device->comp while the second device retains the PFN in its type1 iommu_domain.
Jason