Linux kernel (drivers/iommu/iommufd): Splitting a mapping area - which is what a partial unmap does - leaves the

Impact

Splitting a mapping area - which is what a partial unmap does - leaves the domains interval tree pointing at the old node. Upstream states the outcome plainly as a use-after-free. That tree is what maps IOVA ranges to the IOMMU domains they are programmed into, so corrupting it also means invalidation and teardown target the wrong ranges, leaving live DMA windows behind.

Who can reach it

A holder of /dev/iommu issuing an unmap that falls inside an existing mapping on an IOAS with a domain attached - completely routine VMM behaviour, not a crafted edge case. No host root, no special hardware beyond iommufd being in use.

What to do

The record lists no fixed release; boot a kernel carrying the stable fix commits below. Interim control: do not expose /dev/iommu to tenants.

References

Related entries

• Linux kernel (drivers/iommu/iommufd): An unmap runs off the end of the pinned page list and drops pin counts on pagesCVE-2023-53630 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): The same hardware page table gets linked into an address space's page-table listCVE-2023-54043 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): The pfn batch end index is left at zero after a carry, so the unpin path walks anCVE-2023-54060 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): The IOVA allocator's alignment arithmetic wraps near ULONG_MAX and yields aCVE-2025-38688 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): Iommufd tears down the page-tracking state behind a dma-buf backed IOAS mappingCVE-2026-74328 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): The pfn batch carries the wrong page-frame number forward when a mapping spans aCVE-2023-53236 · Linux kernel (drivers/iommu/iommufd)High