Re: [PATCH rc v2 0/4] iommufd: Fix veventq_depth boundary

[Jason Gunthorpe]

On Thu, May 21, 2026 at 05:36:31PM -0700, Nicolin Chen wrote:
> 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/cover.1779070992.git.nicolinc@xxxxxxxxxx/
> 
> 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

I applied this a few days ago

Jason