Re: [PATCH 2/3] fpga: dfl-afu: fix integer truncation of npages in afu_dma_pin_pages()

[Greg KH <gregkh@linuxfoundation.org>]

Please reply inline with the real message, not just at the top...

On Thu, Apr 02, 2026 at 10:25:14AM -0600, Sebastián Alba wrote:
> On Thu, Apr 02, 2026 at 10:07:00AM, Greg KH wrote:
> > How can length be that large?  You are shifting down, not up.
> 
> region->length comes from userspace via the DFL_FPGA_PORT_DMA_MAP
> ioctl (struct dfl_fpga_port_dma_map.length, __u64). The only
> validation in afu_dma_map_region() is PAGE_ALIGNED and an overflow
> check (user_addr + length < user_addr), but there is no upper bound.
> So length >> PAGE_SHIFT can still exceed INT_MAX.
> 
> > Why INT_MAX?  SHouldn't this be much smaller?
> 
> INT_MAX because pin_user_pages_fast() takes int nr_pages. But you
> are right, a practical limit should be much smaller. Happy to use a
> tighter cap if you have a preferred value, or I can base it on
> totalram_pages().

Ok, I think you should move back up the call chain, and for every ioctl,
properly validate ALL arguments before calling 3 levels deep into the
kernel afterwards, and just hope that the values you are passing around
then are actually valid.

Same for the firmware verification, that should all be done in one
place, before you start poking around in the image.  Try to treat all
data coming from userspace, or a firmware image, as "unverified" and it
must be verified before it can cross the boundry to being trusted to do
anything with it.

I'm guessing you have access to some "bad" firmware images to test this
out with?   This is a very odd driver, I doubt that anyone has thrown
any untrusted data at it before.

thanks,

greg k-h