All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: [PATCH 1/8] drm/fb: More paranoia in addfb checks
Date: Fri, 15 Nov 2019 10:21:13 +0100	[thread overview]
Message-ID: <20191115092120.4445-2-daniel.vetter@ffwll.ch> (raw)
In-Reply-To: <20191115092120.4445-1-daniel.vetter@ffwll.ch>

- 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. Hence two steps. Also go with the more common (and imo
  safer approach) 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)
 			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

_______________________________________________
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: Daniel Vetter <daniel.vetter@ffwll.ch>
To: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Subject: [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks
Date: Fri, 15 Nov 2019 10:21:13 +0100	[thread overview]
Message-ID: <20191115092120.4445-2-daniel.vetter@ffwll.ch> (raw)
Message-ID: <20191115092113.MePYGxWEdolPHfet5glvCFWIaCPbG499gdl_w5lXLCo@z> (raw)
In-Reply-To: <20191115092120.4445-1-daniel.vetter@ffwll.ch>

- 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. Hence two steps. Also go with the more common (and imo
  safer approach) 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)
 			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

  reply	other threads:[~2019-11-15  9:21 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 ` Daniel Vetter [this message]
2019-11-15  9:21   ` [Intel-gfx] [PATCH 1/8] drm/fb: More paranoia in addfb checks 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ä
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=20191115092120.4445-2-daniel.vetter@ffwll.ch \
    --to=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.