Re: [PATCH v2 3/3] drivers/iommu: Catch scatterlist length overflows

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Jul 03, 2026 at 07:58:32PM +0100, Robin Murphy wrote:
> On 03/07/2026 5:22 pm, Jason Gunthorpe wrote:
> > On Wed, Jul 01, 2026 at 10:44:37AM +0000, Krzysztof Karas wrote:
> > > It is possible, when a very large mapping uses a single
> > > scatterlist, that padding overflows scatterlist's length field.
> > > This results in:
> > >   1) silently wrapping the value
> > >   2) smaller than desired mappings produced by iommu_map_sg
> > >   3) leaving mapped bytes in memory (no iommu_unmap)
> > > 
> > > Address this issue by adding overflow detection for previous
> > > scatterlist length field.
> > 
> > Urk, this is unfortunate, it means we cannot map certain kinds of
> > scatterlists? Meaning there is a condition that makes a scatterlist
> > ill formed?
> > 
> > This seems like something that needs to be more clearly documented and
> > we need to ensure at least the common scatterlist builders don't hit
> > it..
> 
> Well, it's taken 10 years to be caught by a test which seemingly expects the
> mapping of a single absurdly giant scatterlist to fail anyway,

If your server has 0.5TB of ram a 4G IO isn't actually that large.
Randomly getting a few contiguous 1G hugetlbfs pages is not even that
unlikely. Something like FSDAX has a very high chance of getting high
contiguity pages in files.

So I wouldn't be quite so dismissive that this is not something a real
user can hit.

> here, but I suspect this is likely just regular iova_granule rounding
> overflowing when the segment boundary is the maximum 4GB, since the largest
> representable segment length is 4GB - 1. 

It looks like the iommu_dma_map_sg() algorithm only works reliably if
the scatterlist entry size is less than UINT_MAX/2, otherwise it can
risk overflowing when it pads.

API wise I expect any arbitary input to sg_alloc_table_from_pages() to
result in a scatterlist that iommu_dma_map_sg() will map. This
patch highlights there are cornere cases where that isn't true, it
should be fixed..

I agree we shouldn't overcomplicate iommu_dma_map_sg(), so the
simplest fix is to introduce a SG_MAX_LENGTH set to UINT_MAX/2,
justified by the logic in iommu_dma_map_sg(). Fixup the core sg_alloc
code to respect that. WARN_ON in iommu_dma_map_sg() if a malformed
scatterlist entry is presented. Add a WARN_ON under DMA debugging
kconfig as well for the physical path.

DRM would then have to generate scatterlists with a max segment size.

Jason