[Intel-gfx] [PATCH v5 3/7] drm/i915: Check for integer truncation on scatterlist creation

Andrzej Hajda andrzej.hajda at intel.com
Mon Jul 25 11:51:59 UTC 2022


On 25.07.2022 11:25, Gwan-gyeong Mun wrote:
> From: Chris Wilson <chris at chris-wilson.co.uk>
> 
> There is an impedance mismatch between the scatterlist API using unsigned
> int and our memory/page accounting in unsigned long. That is we may try
> to create a scatterlist for a large object that overflows returning a
> small table into which we try to fit very many pages. As the object size
> is under control of userspace, we have to be prudent and catch the
> conversion errors.
> 
> To catch the implicit truncation as we switch from unsigned long into the
> scatterlist's unsigned int, we use overflows_type check and report
> E2BIG prior to the operation. This is already used in our create ioctls to
> indicate if the uABI request is simply too large for the backing store.
> Failing that type check, we have a second check at sg_alloc_table time
> to make sure the values we are passing into the scatterlist API are not
> truncated.
> 
> It uses pgoff_t for locals that are dealing with page indices, in this
> case, the page count is the limit of the page index.
> And it uses safe_conversion() macro which performs a type conversion (cast)
> of an integer value into a new variable, checking that the destination is
> large enough to hold the source value.
> 
> v2: Move added i915_utils's macro into drm_util header (Jani N)
> v5: Fix macros to be enclosed in parentheses for complex values
>      Fix too long line warning
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun at intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Cc: Brian Welty <brian.welty at intel.com>
> Cc: Matthew Auld <matthew.auld at intel.com>
> Cc: Thomas Hellström <thomas.hellstrom at linux.intel.com>
> Reviewed-by: Nirmoy Das <nirmoy.das at intel.com>
> Reviewed-by: Mauro Carvalho Chehab <mchehab at kernel.org>
Reviewed-by: Andrzej Hajda <andrzej.hajda at intel.com>

Regards
Andrzej


More information about the Intel-gfx mailing list