Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Page tables are freed before deleting the device domain from the hypervisor, leading to a Use-After-Free risk. --
--- Patch [4]: [PATCH v4 4/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest --- commit 7152dacb77d4624afa4df5d0624b6de801e9959e Author: Yu Zhang <[email protected]> iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest This commit adds a para-virtualized IOMMU driver for Linux guests on Hyper-V. It implements stage-1 IO translation in the guest OS and integrates with the Linux IOMMU core utilizing Hyper-V hypercalls. > diff --git a/drivers/iommu/hyperv/hv-iommu-guest.c > b/drivers/iommu/hyperv/hv-iommu-guest.c > new file mode 100644 > --- /dev/null > +++ b/drivers/iommu/hyperv/hv-iommu-guest.c [ ... ] > +static void hv_iommu_paging_domain_free(struct iommu_domain *domain) > +{ > + struct hv_iommu_domain *hv_domain = to_hv_iommu_domain(domain); > + > + /* Free all remaining mappings */ > + pt_iommu_deinit(&hv_domain->pt_iommu); > + > + hv_delete_device_domain(hv_domain); [Severity: High] Could this cause a use-after-free of guest memory? The guest kernel frees the page tables by calling pt_iommu_deinit() first, returning the physical pages to the allocator while the hypervisor still holds a reference to the page table root for this device domain. If the hypervisor accesses the page tables during the subsequent HVCALL_DELETE_DEVICE_DOMAIN hypercall (for cleanup, nested cache flushes, or shadow unmapping), it might read or write to reallocated memory. Should hv_delete_device_domain() be called before pt_iommu_deinit(), similar to how teardown is ordered in the hv_iommu_domain_alloc_paging() error path? > + > + kfree(hv_domain); > +} [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=4
