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
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
