All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: Re: [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks
Date: Fri, 15 Nov 2019 14:44:11 +0200	[thread overview]
Message-ID: <20191115124411.GC1208@intel.com> (raw)
In-Reply-To: <20191115092120.4445-2-daniel.vetter@ffwll.ch>

On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
> 
> - Untangle the one overflow check, I think (but not sure) that with
>   all three together you could overflow the uint64_t and it'd look
>   cool again.

It can't overflow. All theree inputs are u32 so the max value
you can get is 0xffffffff00000000.

> Hence two steps. Also go with the more common (and imo
>   safer approach) 

Also results in multiple divisions which is needlessly expensive.
The original is just mul+add.

> of reducing the range we accept, instead of trying
>   to compute the overflow in high enough precision.
> 
> - The above would blow up if we get a 0 pitches, so check for that
>   too, but only if block_size is a thing.
> 
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..3141c6ed6dd2 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
>  			return -EINVAL;
>  		}
>  
> -		if (min_pitch > UINT_MAX)
> +		if (min_pitch > U8_MAX)

U8?

>  			return -ERANGE;
>  
> -		if ((uint64_t) height * r->pitches[i] + r->offsets[i] > UINT_MAX)
> -			return -ERANGE;
> +		if (block_size) {
> +			if (r->pitches[i] < min_pitch) {
> +				DRM_DEBUG_KMS("bad pitch %u for plane %d\n", r->pitches[i], i);
> +				return -EINVAL;
> +			}
>  
> -		if (block_size && r->pitches[i] < min_pitch) {
> -			DRM_DEBUG_KMS("bad pitch %u for plane %d\n", r->pitches[i], i);
> -			return -EINVAL;
> +			if (height > U8_MAX / r->pitches[i])
> +				return -ERANGE;
> +
> +			if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
> +				return -ERANGE;
>  		}
>  
>  		if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> -- 
> 2.24.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: Re: [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks
Date: Fri, 15 Nov 2019 14:44:11 +0200	[thread overview]
Message-ID: <20191115124411.GC1208@intel.com> (raw)
Message-ID: <20191115124411.dngANxtX-G3QF_mm1I1IDDzb7AN5QMxldJbI9WK7zmQ@z> (raw)
In-Reply-To: <20191115092120.4445-2-daniel.vetter@ffwll.ch>

On Fri, Nov 15, 2019 at 10:21:13AM +0100, Daniel Vetter wrote:
> - Our limit is uint32_t, make that explicit.
> 
> - Untangle the one overflow check, I think (but not sure) that with
>   all three together you could overflow the uint64_t and it'd look
>   cool again.

It can't overflow. All theree inputs are u32 so the max value
you can get is 0xffffffff00000000.

> Hence two steps. Also go with the more common (and imo
>   safer approach) 

Also results in multiple divisions which is needlessly expensive.
The original is just mul+add.

> of reducing the range we accept, instead of trying
>   to compute the overflow in high enough precision.
> 
> - The above would blow up if we get a 0 pitches, so check for that
>   too, but only if block_size is a thing.
> 
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..3141c6ed6dd2 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -214,15 +214,20 @@ static int framebuffer_check(struct drm_device *dev,
>  			return -EINVAL;
>  		}
>  
> -		if (min_pitch > UINT_MAX)
> +		if (min_pitch > U8_MAX)

U8?

>  			return -ERANGE;
>  
> -		if ((uint64_t) height * r->pitches[i] + r->offsets[i] > UINT_MAX)
> -			return -ERANGE;
> +		if (block_size) {
> +			if (r->pitches[i] < min_pitch) {
> +				DRM_DEBUG_KMS("bad pitch %u for plane %d\n", r->pitches[i], i);
> +				return -EINVAL;
> +			}
>  
> -		if (block_size && r->pitches[i] < min_pitch) {
> -			DRM_DEBUG_KMS("bad pitch %u for plane %d\n", r->pitches[i], i);
> -			return -EINVAL;
> +			if (height > U8_MAX / r->pitches[i])
> +				return -ERANGE;
> +
> +			if (r->offsets[i] > U8_MAX / r->pitches[i] - height)
> +				return -ERANGE;
>  		}
>  
>  		if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
> -- 
> 2.24.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-11-15 12:44 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15  9:21 [PATCH 0/8] fb_create drive-through cleanups Daniel Vetter
2019-11-15  9:21 ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 1/8] drm/fb: More paranoia in addfb checks Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15 10:49   ` Pekka Paalanen
2019-11-15 10:49     ` [Intel-gfx] " Pekka Paalanen
2019-11-15 12:44   ` Ville Syrjälä [this message]
2019-11-15 12:44     ` Ville Syrjälä
2019-11-15 15:26     ` Daniel Vetter
2019-11-15 15:26       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 2/8] drm/atmel: ditch fb_create wrapper Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:33   ` Boris Brezillon
2019-11-15  9:33     ` [Intel-gfx] " Boris Brezillon
2019-11-15  9:33     ` Boris Brezillon
2019-11-19 21:22     ` Daniel Vetter
2019-11-19 21:22       ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:22       ` Daniel Vetter
2019-11-23  8:49       ` Sam Ravnborg
2019-11-23  8:49         ` [Intel-gfx] " Sam Ravnborg
2019-11-23  8:49         ` Sam Ravnborg
2019-11-23  8:49         ` Sam Ravnborg
2019-11-15  9:21 ` [PATCH 3/8] drm/mediatek: don't open-code drm_gem_fb_create Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-22  7:42   ` CK Hu
2019-11-22  7:42     ` [Intel-gfx] " CK Hu
2019-11-22  7:42     ` CK Hu
2019-11-22  7:42     ` CK Hu
2019-11-22 17:09     ` Daniel Vetter
2019-11-22 17:09       ` [Intel-gfx] " Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-22 17:09       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 4/8] drm/rockchip: Use drm_gem_fb_create_with_dirty Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-27 11:45   ` Andrzej Pietrasiewicz
2019-11-27 11:45     ` [Intel-gfx] " Andrzej Pietrasiewicz
2019-11-27 11:45     ` Andrzej Pietrasiewicz
2019-11-27 11:45     ` Andrzej Pietrasiewicz
2019-11-27 17:33   ` Andrzej Pietrasiewicz
2019-11-27 17:33     ` [Intel-gfx] " Andrzej Pietrasiewicz
2019-11-27 17:33     ` Andrzej Pietrasiewicz
2019-11-27 17:54     ` Daniel Vetter
2019-11-27 17:54       ` [Intel-gfx] " Daniel Vetter
2019-11-27 17:54       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 5/8] drm/tilcdc: Drop drm_gem_fb_create wrapper Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-15 13:21   ` Jyri Sarha
2019-11-15 13:21     ` [Intel-gfx] " Jyri Sarha
2019-11-15 13:21     ` Jyri Sarha
2019-11-19 21:25     ` Daniel Vetter
2019-11-19 21:25       ` [Intel-gfx] " Daniel Vetter
2019-11-19 21:25       ` Daniel Vetter
2019-11-15  9:21 ` [PATCH 6/8] drm/xen: Simplify fb_create Daniel Vetter
2019-11-15  9:21   ` [Xen-devel] " Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15 10:33   ` Oleksandr Andrushchenko
2019-11-15 10:33     ` [Xen-devel] " Oleksandr Andrushchenko
2019-11-15 10:33     ` [Intel-gfx] " Oleksandr Andrushchenko
2019-11-15 10:33     ` Oleksandr Andrushchenko
2019-11-19 21:25     ` Daniel Vetter
2019-11-19 21:25       ` [Xen-devel] " Daniel Vetter
2019-11-19 21:25       ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` [PATCH 7/8] drm/hibmc: Use drm_gem_fb_create Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-22  8:09   ` Thomas Zimmermann
2019-11-22  8:09     ` [Intel-gfx] " Thomas Zimmermann
2019-11-22  8:16   ` Thomas Zimmermann
2019-11-22  8:16     ` [Intel-gfx] " Thomas Zimmermann
2019-11-22  9:12     ` Daniel Vetter
2019-11-22  9:12       ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21 ` [PATCH 8/8] drm/todo: Add entry for fb funcs related cleanups Daniel Vetter
2019-11-15  9:21   ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:21   ` Daniel Vetter
2019-11-20 10:46   ` Daniel Vetter
2019-11-20 10:46     ` [Intel-gfx] " Daniel Vetter
2019-11-15  9:30 ` ✗ Fi.CI.CHECKPATCH: warning for fb_create drive-through cleanups Patchwork
2019-11-15  9:30   ` [Intel-gfx] " Patchwork
2019-11-15  9:50 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-11-15  9:50   ` [Intel-gfx] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191115124411.GC1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=pekka.paalanen@collabora.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.