The upper bound of veventq_depth has been missing for veventq allocation, leaving a vulnerability where userspace could exhaust atomic memory pool.
Fix it properly: - Allocate outside the spinlock to avoid GFP_ATOMIC - Cap the veventq_depth upper bound - Fix event_data byte-count - Add selftest coverage Note that QEMU's SMMU has been already allocating veventq using a "HW" EVTQ entry number. So, picking 19 as the known use case, for a minimal level of ABI consistency. This is on github: https://github.com/nicolinc/iommufd/commits/fix_veventq_depth-v2 Changelog: v2 * Add Reviewed-by from Jason * Rebase on Jason's for-rc tree * Update commit message for clarification * Move "data_len byte-count" to the first * Drop optimistic read in the allocation path v1 https://lore.kernel.org/all/[email protected]/ Nicolin Chen (4): iommufd: Fix data_len byte-count vs element-count mismatch iommufd: Move vevent memory allocation outside spinlock iommufd: Set veventq_depth upper bound iommufd/selftest: Add boundary tests for veventq_depth drivers/iommu/iommufd/iommufd_private.h | 2 +- tools/testing/selftests/iommu/iommufd_utils.h | 17 +++++++++-------- drivers/iommu/iommufd/driver.c | 13 ++++++++----- drivers/iommu/iommufd/eventq.c | 5 ++++- tools/testing/selftests/iommu/iommufd.c | 19 +++++++++++++++++-- .../selftests/iommu/iommufd_fail_nth.c | 2 +- 6 files changed, 40 insertions(+), 18 deletions(-) base-commit: be93d186ae88a92e7aa77e122d4e661fa57b1e39 -- 2.43.0
