From: sashiko-bot@kernel.org
To: "Rob Clark" <robin.clark@oss.qualcomm.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/msm/gem: Fix VM_BIND range check
Date: Sun, 01 Nov 2026 18:02:23 +0000 [thread overview]
Message-ID: <sashiko-outbox-192555@kernel.org> (raw)
In-Reply-To: <20261101174911.25184-2-robin.clark@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/msm: 64-to-32-bit truncation in size_add() in vm_bind_job_lookup_ops()
--
commit 0bb1fc19abe2c004d338802c56cd54e0621aa9a6
Author: Rob Clark <robin.clark@oss.qualcomm.com>
drm/msm/gem: Fix VM_BIND range check
This commit replaces the addition of op->range and op->obj_offset with
size_add() in vm_bind_job_lookup_ops() to guard against integer overflow when
validating the range against obj->size.
> diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c b/drivers/gpu/drm/msm/msm_gem_vma.c
> index f687a629629d3..16b3870d5e90e 100644
> --- a/drivers/gpu/drm/msm/msm_gem_vma.c
> +++ b/drivers/gpu/drm/msm/msm_gem_vma.c
> @@ -1118,7 +1118,7 @@ vm_bind_job_lookup_ops(struct msm_vm_bind_job *job, struct drm_msm_vm_bind *args
> op->obj = obj;
> cnt++;
>
> - if ((op->range + op->obj_offset) > obj->size) {
> + if (size_add(op->range, op->obj_offset) > obj->size) {
[Severity: Medium]
On 32-bit builds, does passing op->range and op->obj_offset to size_add()
truncate the upper 32 bits of both 64-bit operands before checking for
overflow?
In struct msm_vm_bind_op, obj_offset and range are 64-bit values:
drivers/gpu/drm/msm/msm_gem_vma.c:
struct msm_vm_bind_op {
...
uint64_t obj_offset;
uint64_t iova;
uint64_t range;
...
};
However, size_add() in include/linux/overflow.h takes size_t arguments:
static __always_inline size_t __must_check size_add(size_t addend1, size_t addend2)
Earlier in lookup_op(), op->obj_offset is only checked with
invalid_alignment(op->obj_offset), which does not reject non-zero upper 32
bits. On 32-bit architectures where size_t is 32 bits wide, an offset such as
0x100000000ULL is truncated to 0 when passed to size_add(), allowing an
out-of-bounds 64-bit op->obj_offset or op->range to bypass the obj->size
check in vm_bind_job_lookup_ops() and be stored into vma->gem.offset.
Would check_add_overflow() with a uint64_t sum (or range_overflows_t(u64,
op->obj_offset, op->range, obj->size)) avoid narrowing the operands on 32-bit
targets?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261101174911.25184-1-robin.clark@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-11-01 18:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 17:49 [PATCH 0/2] drm/msm/gem: A couple VM_BIND fixes Rob Clark
2026-11-01 17:49 ` [PATCH 1/2] drm/msm/gem: Fix VM_BIND range check Rob Clark
2026-11-01 18:02 ` sashiko-bot [this message]
2026-11-02 9:40 ` Konrad Dybcio
2026-11-02 10:27 ` Dmitry Baryshkov
2026-11-02 13:59 ` Rob Clark
2026-11-02 15:18 ` Rob Clark
2026-11-02 15:26 ` Konrad Dybcio
2026-11-02 10:27 ` Dmitry Baryshkov
2026-11-01 17:49 ` [PATCH 2/2] drm/msm/gem: Disallow nr_bos for VM_BIND contexts Rob Clark
2026-11-02 10:28 ` Dmitry Baryshkov
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=sashiko-outbox-192555@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.