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 iommu/arm-smmu-v3: Process vIOMMU invalidations in batches include/linux/iommu.h | 1 + .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 91 +++++++++++-------- drivers/iommu/iommufd/hw_pagetable.c | 11 ++- tools/testing/selftests/iommu/iommufd.c | 15 +++ 4 files changed, 81 insertions(+), 37 deletions(-) -- 2.43.0
