On Sun, May 19, 2024 at 07:06:45PM -0400, Kent Overstreet wrote: > this looks like an i915 bug Yeah, agreed. > On Wed, May 15, 2024 at 10:41:19AM +0800, kernel test robot wrote: [...] > > [test failed on linux-next/master 6ba6c795dc73c22ce2c86006f17c4aa802db2a60] [...] > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot <oliver.sang@xxxxxxxxx> > > | Closes: https://lore.kernel.org/oe-lkp/202405151008.6ddd1aaf-oliver.sang@xxxxxxxxx > > > > > > [ 940.101700][ T5353] ------------[ cut here ]------------ > > [ 940.107107][ T5353] WARNING: CPU: 1 PID: 5353 at mm/util.c:649 kvmalloc_node_noprof (mm/util.c:649 (discriminator 1)) This is: /* Don't even allow crazy sizes */ if (unlikely(size > INT_MAX)) { WARN_ON_ONCE(!(flags & __GFP_NOWARN)); > > [ 940.307791][ T5353] Call Trace: [...] > > [ 940.351795][ T5353] eb_copy_relocations (drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1685) i915 And this is: const unsigned int nreloc = eb->exec[i].relocation_count; ... size = nreloc * sizeof(*relocs); relocs = kvmalloc_array(1, size, GFP_KERNEL); So something isn't checking the "relocation_count" size that I assume is coming in from the ioctl? -Kees -- Kees Cook
