On Wed, Jun 03, 2026 at 02:26:52PM -0700, Nicolin Chen wrote: > Sashiko pointed out several issues in the iommufd invalidation path, which > also prompted a rework of the ARM SMMUv3 vIOMMU invalidation handler: > > - entry_len is user-controlled and unbounded, so the trailing-zero check > for its forward-compat fields can scan gigabytes of user memory without > yielding, long enough to trip the soft-lockup watchdog. > > - A large entry_num drives a backend's per-entry invalidation loop with no > reschedule, e.g. the VT-d nested path, pinning the CPU. > > - The full-array copy helper copies the array twice on the equal-size fast > path: once in bulk, then again entry by entry. > > - arm_vsmmu_cache_invalidate() reports converted-but-unsubmitted commands > as handled on its error paths. > > - It sizes a single kernel allocation from the user-controlled entry_num. > > - It rejects an empty-array data_type probe that the uAPI allows. > > Fix them properly. > > This is on Github: > https://github.com/nicolinc/iommufd/commits/smmuv3_fix_iommufd-v1 > > Nicolin Chen (4): > iommufd: Set upper bounds on cache invalidation entry_num and > entry_len > iommufd/selftest: Add invalidation entry_num and entry_len boundary > tests > iommu: Avoid copying the user array twice in the full-array copy > helper
I picked up these ones, lets resend this next cycle for Will: > iommu/arm-smmu-v3: Process vIOMMU invalidations in batches Thanks, Jason
