Since scatterlist dimensions are all unsigned ints, in the relatively rare cases where a device's max_segment_size is set to UINT_MAX, then the "cur_len + s_length <= max_len" check in __finalise_sg() will always return true. As a result, the corner case of such a device mapping an excessively large scatterlist which is mergeable to or beyond a total length of 4GB can lead to overflow and a bogus truncated dma_length in the resulting segment. As we already assume that any single segment must be no longer than max_len to begin with, this can easily be addressed by reshuffling the comparison. Fixes: 809eac54cdd6 ("iommu/dma: Implement scatterlist segment merging") Reported-by: Nicolin Chen <nicoleotsuka@gmail.com> Tested-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/iommu/dma-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index a7f9c3edbcb2..e3098bc0996c 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -764,7 +764,7 @@ static int __finalise_sg(struct device *dev, struct scatterlist *sg, int nents, * - and wouldn't make the resulting output segment too long */ if (cur_len && !s_iova_off && (dma_addr & seg_mask) && - (cur_len + s_length <= max_len)) { + (max_len - cur_len >= s_length)) { /* ...then concatenate it with the previous one */ cur_len += s_length; } else { -- 2.21.0.dirty _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin, On Mon, Jul 29, 2019 at 05:46:00PM +0100, Robin Murphy wrote: > Since scatterlist dimensions are all unsigned ints, in the relatively > rare cases where a device's max_segment_size is set to UINT_MAX, then > the "cur_len + s_length <= max_len" check in __finalise_sg() will always > return true. As a result, the corner case of such a device mapping an > excessively large scatterlist which is mergeable to or beyond a total > length of 4GB can lead to overflow and a bogus truncated dma_length in > the resulting segment. > > As we already assume that any single segment must be no longer than > max_len to begin with, this can easily be addressed by reshuffling the > comparison. Has this been triggered in the wild of can this patch wait for the next merge window? Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Joerg, On 06/08/2019 16:25, Joerg Roedel wrote: > Hi Robin, > > On Mon, Jul 29, 2019 at 05:46:00PM +0100, Robin Murphy wrote: >> Since scatterlist dimensions are all unsigned ints, in the relatively >> rare cases where a device's max_segment_size is set to UINT_MAX, then >> the "cur_len + s_length <= max_len" check in __finalise_sg() will always >> return true. As a result, the corner case of such a device mapping an >> excessively large scatterlist which is mergeable to or beyond a total >> length of 4GB can lead to overflow and a bogus truncated dma_length in >> the resulting segment. >> >> As we already assume that any single segment must be no longer than >> max_len to begin with, this can easily be addressed by reshuffling the >> comparison. > > Has this been triggered in the wild of can this patch wait for the next > merge window? My impression was that it's possible to hit this via relatively funky, but legitimate, use of dma-buf from userspace, however I don't know off-hand how many drivers actually support creating and exporting such crazy-large buffers in the first place. Nicolin - is your use-case something that's easy to do with standard software on stable kernels, or did it only come to light as part of a "big stack of embedded magic" type thing? Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin, On Tue, Aug 06, 2019 at 04:49:01PM +0100, Robin Murphy wrote: > Hi Joerg, > > On 06/08/2019 16:25, Joerg Roedel wrote: > > Hi Robin, > > > > On Mon, Jul 29, 2019 at 05:46:00PM +0100, Robin Murphy wrote: > > > Since scatterlist dimensions are all unsigned ints, in the relatively > > > rare cases where a device's max_segment_size is set to UINT_MAX, then > > > the "cur_len + s_length <= max_len" check in __finalise_sg() will always > > > return true. As a result, the corner case of such a device mapping an > > > excessively large scatterlist which is mergeable to or beyond a total > > > length of 4GB can lead to overflow and a bogus truncated dma_length in > > > the resulting segment. > > > > > > As we already assume that any single segment must be no longer than > > > max_len to begin with, this can easily be addressed by reshuffling the > > > comparison. > > > > Has this been triggered in the wild of can this patch wait for the next > > merge window? > > My impression was that it's possible to hit this via relatively funky, but > legitimate, use of dma-buf from userspace, however I don't know off-hand how > many drivers actually support creating and exporting such crazy-large > buffers in the first place. > > Nicolin - is your use-case something that's easy to do with standard > software on stable kernels, or did it only come to light as part of a "big > stack of embedded magic" type thing? Well..it was triggered in our downstream test that's supposed to cover large size (> 4G) corner case, so I don't feel it's "easy" but our test case was running with 4.14 kernel so I also feel it might be a good idea to Cc stable kernel even if we postpone the patch during the merge window. I'll personally be fine with any decision though -- if no one else cares that much, I'll backport to our downstream 4.14 on my own. As a reference, here is a partial list of mainline drivers that were potentially affected, and are now secured by this change: drivers/dma/dw-edma/dw-edma-core.c:745: dma_set_max_seg_size(dma->dev, U32_MAX); drivers/dma/dma-axi-dmac.c:871: dma_set_max_seg_size(&pdev->dev, UINT_MAX); drivers/mmc/host/renesas_sdhi_internal_dmac.c:338: dma_set_max_seg_size(dev, 0xffffffff); drivers/nvme/host/pci.c:2520: dma_set_max_seg_size(dev->dev, 0xffffffff); Above all, thanks for the fix. Nicolin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Aug 06, 2019 at 06:11:51PM -0700, Nicolin Chen wrote: > Well..it was triggered in our downstream test that's supposed to > cover large size (> 4G) corner case, so I don't feel it's "easy" > but our test case was running with 4.14 kernel so I also feel it > might be a good idea to Cc stable kernel even if we postpone the > patch during the merge window. I'll personally be fine with any > decision though -- if no one else cares that much, I'll backport > to our downstream 4.14 on my own. Okay, decided to apply it for v5.3. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu