On Sun, May 17, 2026 at 07:28:45PM -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-v1 > > Nicolin Chen (4): > iommufd: Move vevent memory allocation outside spinlock > iommufd: Set veventq_depth upper bound > iommufd: Fix data_len byte-count vs element-count mismatch > iommufd/selftest: Add boundary tests for veventq_depth
Please adjust for the sashiko remarks: 1) Put "iommufd: Fix data_len byte-count vs element-count mismatch" first 2) This "Returning -ENOMEM for allocation failures but 0 for queue overflows treats the conditions differently, which seems to contradict the stated intent." Seems bogus, I think adjust the commit message. We do want 0 for queue full conditions. 3) Let's fix the "Will this lockless read concurrent with a plain write cause a data race?" by removing the optimization, just pre-allocate and fail. We don't expect this to be a normal condition worth optimizing 4) I'm OK with ENOMEM here, leave it, EAGAIN should mean it is pollable and it won't become pollable.. 5) The sizeof(hdr) has been fixed in my rc branch. You can rebase on top of that and also ensure to send a base-commit trailer to help Sashiko apply the patches properly 6) What do you think about the "but done has already been incremented by sizeof(*hdr)" ? unrelated issue? If it is simple lets add a patch here to fix it Jason
