From nobody Mon Jun 8 05:26:22 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FDAB36A373 for ; Fri, 5 Jun 2026 14:27:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780669685; cv=none; b=ZHYBsju55WTtktOw2H0wKbzSexRomCsfbBz3X+aiT3gfBXY+HC42GDQe7Se2VCewGwXzPIjkXV362uEFou3lh620zUS41ixVN44oDwxh0eim0n4/+7zb11hATXLQzPNfnqwgPwSm5CVxGM4F6vfgOLvZO/Abu/o+oWSYms7gVFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780669685; c=relaxed/simple; bh=9+2tJyEMrAs0aVzFwPUn+cI7xtuaHQeZnLCfHSlxA4I=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Zx292SpOK5fDw6LjIwfv/SCv4uBJXspJiL5HNzAJv5yQJxZY2+YQj72d5x7ceDRJjFDGpgxs2W+3BEN1hs3AlFgmNkBwnp2KDedd9NzV8l3aIEgfA6d2XscIBnyfSvm8EXAq6wuXmCTElmvRGv+4f97aRZuBOit6fdv+Qelo2cI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=p8YE/DuL; arc=none smtp.client-ip=220.197.31.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="p8YE/DuL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=uk BNaSy4Bu2Lvfy5mgAamxv2wNVl4pikiN6hS0u3/sA=; b=p8YE/DuLmQwM/dIrrD SccB8NyvVw9O25FgWJGIvlk3/5u5YbhhOuPQrN5fm9pCKex7emCS3PYDsWiz+LU1 QPEsFuHRQO4/v34JGwp6KtR4cOmbSX4Ce9wpkOXJ0mJnPaXYxtu1MSSl1kyPjaKR khq7djorIvnx8CQeVsw9Y278U= Received: from 163.com (unknown []) by gzga-smtp-mtada-g1-2 (Coremail) with SMTP id _____wD3vZOn3CJqBZl+Bg--.39839S2; Fri, 05 Jun 2026 22:26:52 +0800 (CST) From: w15303746062@163.com To: maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Mingyu Wang <25181214217@stu.xidian.edu.cn> Subject: [PATCH v2] drm/gem: fix signed integer overflow in idr_alloc end parameter Date: Fri, 5 Jun 2026 22:26:44 +0800 Message-Id: <20260605142644.1205922-1-w15303746062@163.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wD3vZOn3CJqBZl+Bg--.39839S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7CFyfZr4DAw4kWr45XryftFb_yoW8uFWxpa 9rGryjvrWUKFs2qF12van3JFyfC3WSgFW8GFZYv390vw1UJ3Za9r90kay5trW7CrWxuF4a q345tr9YvF1UCaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j75rxUUUUU= X-CM-SenderInfo: jzrvjiatxuliiws6il2tof0z/xtbC5AyFaWoi3Kwt-QAA3s Content-Type: text/plain; charset="utf-8" From: Mingyu Wang <25181214217@stu.xidian.edu.cn> During code review of drm_gem_change_handle_ioctl(), a signed integer overflow vulnerability was identified. The function currently checks if args->new_handle is strictly greater than INT_MAX. However, if args->new_handle is exactly INT_MAX, the subsequent call to idr_alloc() uses 'handle + 1' as the end limit. Since 'handle' is a signed int, passing INT_MAX results in a signed integer overflow (INT_MAX + 1 =3D -2147483648). While idr_alloc() handles negative end values by gracefully falling back to INT_MAX, this breaks the exact-ID allocation semantics intended by the caller and relies on undefined behavior. Additionally, explicitly reject args->new_handle =3D=3D 0. In the DRM subsystem, 0 is universally treated as an invalid handle. Allowing an object to be aliased to handle 0 breaks core DRM assumptions (e.g., drm_gem_object_lookup returns NULL for 0). Fix this by tightening the limit check to >=3D INT_MAX to prevent the overflow, and explicitly reject 0. Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> --- v2: - Add explicit check to reject handle 0, which is invalid in DRM. - Remove redundant (u32) cast; rely on standard C integer promotion. - Shift focus entirely to fixing the handle + 1 signed integer overflow (T= homas Zimmermann). drivers/gpu/drm/drm_gem.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index e12cdf91f4dc..1ad30a700068 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1025,8 +1025,12 @@ int drm_gem_change_handle_ioctl(struct drm_device *d= ev, void *data, if (!drm_core_check_feature(dev, DRIVER_GEM)) return -EOPNOTSUPP; =20 - /* idr_alloc() limitation. */ - if (args->new_handle > INT_MAX) + /* + * idr_alloc() limitation. + * Reject handle 0 (invalid in DRM) and strictly bound + * to < INT_MAX to avoid signed integer overflow in handle + 1. + */ + if (args->new_handle =3D=3D 0 || args->new_handle >=3D INT_MAX) return -EINVAL; handle =3D args->new_handle; =20 --=20 2.34.1