linux-kernel - [PATCH] drm/gem: fix overflow in calculating DMA GEM size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20250228121834.122728-1-a.vatoropin@crpt.ru>
Date: Fri, 28 Feb 2025 12:18:44 +0000
From: Ваторопин Андрей <a.vatoropin@...t.ru>
To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
CC: Ваторопин Андрей <a.vatoropin@...t.ru>, Maxime Ripard
	<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
	<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Thierry Reding
	<treding@...dia.com>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "lvc-project@...uxtesting.org"
	<lvc-project@...uxtesting.org>
Subject: [PATCH] drm/gem: fix overflow in calculating DMA GEM size

From: Andrey Vatoropin <a.vatoropin@...t.ru>

The IOCTL handler drm_mode_create_dumb receives different parameters from
the user, specifically "height", "width" and others. Sanity checks are 
performed on these parameters. However, these parameters are sent to the 
->dumb_create() callback, and during the processing of the "pitch" 
parameter, its value may change. The extent of this change depends on the
driver that exists at the lower level. The thing is that the value of 
"height" is controlled by user as an ioctl parameter and it is not
directly associated with the "pitch" value so the initial sanity checks
can be insufficient.

For example, if at the moment of calling the 
drm_gem_dma_dumb_create_internal() via ->dumb_create() callback the values
are as follows: height equals 2 ^ 27, pitch equals 2^6 then the following
statement: 
	"args->pitch * args->height"
will evaluate to 
	"2 ^ 6 * 2 ^ 27"
and an overflow occurs.

Since a value of type 'u64' is used to store the eventual size, it is
necessary to perform the 64-bit arithmetic to avoid overflow during the
multiplication.

The same thing was done in commit 0f8f8a643000 
("drm/i915/gem: Detect overflow in calculating dumb buffer size")

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 6d1782919dc9 ("drm/cma: Introduce drm_gem_cma_dumb_create_internal()")
Signed-off-by: Andrey Vatoropin <a.vatoropin@...t.ru> 
---
 drivers/gpu/drm/drm_gem_dma_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem_dma_helper.c
index 870b90b78bc4..a8862f6f702a 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -272,8 +272,8 @@ int drm_gem_dma_dumb_create_internal(struct drm_file *file_priv,
 	if (args->pitch < min_pitch)
 		args->pitch = min_pitch;
 
-	if (args->size < args->pitch * args->height)
-		args->size = args->pitch * args->height;
+	if (args->size < mul_u32_u32(args->pitch, args->height))
+		args->size = mul_u32_u32(args->pitch, args->height);
 
 	dma_obj = drm_gem_dma_create_with_handle(file_priv, drm, args->size,
 						 &args->handle);
-- 
2.43.0