Re: [PATCH v2] drm/xe: Add bounds check for num_binds to prevent memory exhaustion

[Matthew Brost <matthew.brost@intel.com>]

On Thu, May 07, 2026 at 08:47:07AM +0200, Thomas Hellström wrote:
> On Thu, 2026-05-07 at 11:23 +0530, Ramesh Adhikari wrote:
> > The xe_vm_bind_ioctl function accepts user-controlled num_binds
> > without
> > bounds checking, allowing arbitrarily large memory allocations. This
> > follows the same vulnerability pattern that was fixed for num_syncs
> > in
> > commit 8e461304009d ("drm/xe: Limit num_syncs to prevent huge
> > allocations").
> > 
> > Add DRM_XE_MAX_BINDS (2048) limit and validate num_binds before
> > allocation.
> > 
> > v2: Increased limit from 1024 to 2048 based on Mesa source analysis:
> >     - Mesa's maximum usage: 960 binds (conformance test dEQP-VK)
> >     - Confirmed by Intel Mesa developer in commit ba6bbdc
> 
> Please use the standard way of referring to commits.
> 
> This is the maximum usage in the conformance suite. That commit does
> not mention maximum usage for applications in the wild, for which we
> can't have any regressions. 
> 

I still think 1k, 2k to artifically too low. The Vk interface for array
of binds doesn't have a limit nor do sync interface either. In case of
sync I believe we found a typical max usage of of something like 10 but
set artifical limit to 1k just be paranoid. I'd up the limit beyond 1k
or 2k to prevent seemly valid use cases from forcing a split fallback in
user space. Even if each individual bind maps to 4k internal (usually
this just a handfull of bytes for the PTE writes) - 2k binds would 8M of
temporary memory. Ofc we can increase this future but I really don't see
the downside of starting with something larger now.

Matt

> 
> >     - 2048 provides 2.13x safety margin while limiting allocation to
> > 64KB
> >     - Prevents unbounded allocation (attacker could send 268M binds =
> > 18.8GB)
> 
> Referring to my previous email, it actually looks like most if not all
> allocations in this path use __GFP_ACCOUNT | __GFP_RETRY_MAYFAIL |
> __GFP_NOWARN, Did you actually verify that a malicious bind
> significantly can exceed the cgroup limits?
> 
> 
> > 
> > Cc: stable@vger.kernel.org
> > 
> > Signed-off-by: Ramesh <adhikari.resume@gmail.com>
> > ---
> >  drivers/gpu/drm/xe/xe_vm.c | 5 +++++
> >  include/uapi/drm/xe_drm.h  | 1 +
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> > index a717a2b8dea..1ff66874f43 100644
> > --- a/drivers/gpu/drm/xe/xe_vm.c
> > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > @@ -3841,6 +3841,11 @@ int xe_vm_bind_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file)
> >  		return -EINVAL;
> >  
> >  	err = vm_bind_ioctl_check_args(xe, vm, args, &bind_ops);
> > +
> > +	if (XE_IOCTL_DBG(xe, args->num_binds > DRM_XE_MAX_BINDS)) {
> > +		err = -EINVAL;
> 
> If we end up concluding that this is indeed needed, we should return 
> -ENOBUFS here to trigger a graceful retry.
> 
> Thanks,
> Thomas
> 
> 
> > +		goto put_vm;
> > +	}
> >  	if (err)
> >  		goto put_vm;
> >  
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index ae2fda23ce7..e666b73c81d 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -1606,6 +1606,7 @@ struct drm_xe_exec {
> >  	__u32 exec_queue_id;
> >  
> >  #define DRM_XE_MAX_SYNCS 1024
> > +#define DRM_XE_MAX_BINDS 2048
> >  	/** @num_syncs: Amount of struct drm_xe_sync in array. */
> >  	__u32 num_syncs;
> >