Hi Jason, On 2026-07-03 at 17:35:02 -0300, Jason Gunthorpe wrote: > 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.. > Thanks for your input!
> 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. So instead of addressing this in iommu, we should focus on guarding in sg logic to prevent the overflows? Or would you rather have this as additional, separate fix placed in this series? > > DRM would then have to generate scatterlists with a max segment size. > > Jason -- Best Regards, Krzysztof
