On Mon, May 25, 2026 at 06:52:38AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <[email protected]>
> > Sent: Friday, May 22, 2026 8:37 AM
> >
> > iommufd_veventq_alloc() accepts any !0 veventq_depth from userspace,
> > with
> > an upper bound at U32_MAX.
> >
> > This leaves a vulnerability where userspace can allocate excessively large
> > queues to exhaust kernel memory reserves.
> >
> > Cap the veventq_depth (maximum number of entries) to 1 << 19, matching
> > the
> > maximum number of entries in the SMMUv3 EVTQ (the largest use case
> > today).
>
> probably add a comment to uapi header that the maximum number of
> supported veventq depth is implementation specific hence user may
> expect -EINVAL returned if the specified value is too large?
Sure.
@@ -1267,7 +1267,9 @@ struct iommu_vevent_tegra241_cmdqv {
* can have multiple FDs for different types, but is confined to one per @type.
* User space should open the @out_veventq_fd to read vEVENTs out of a vEVENTQ,
* if there are vEVENTs available. A vEVENTQ will lose events due to overflow,
- * if the number of the vEVENTs hits @veventq_depth.
+ * if the number of the vEVENTs hits @veventq_depth. The maximum @veventq_depth
+ * is implementation-specific; -EINVAL will be returned if the requested value
+ * exceeds it.
*
* Each vEVENT in a vEVENTQ encloses a struct iommufd_vevent_header followed by
* a type-specific data structure, in a normal case:
Thanks
Nicolin
