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/[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
I applied this a few days ago Jason
