From: sashiko-bot@kernel.org
To: "Wentao Liang" <vulab@iscas.ac.cn>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/tegra: Fix bo reference leak in host1x_reloc_copy_from_user()
Date: Wed, 16 Sep 2026 18:37:23 +0000 [thread overview]
Message-ID: <20260916183724.5ED331F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916182550.2091797-1-vulab@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/tegra: type confusion and memory corruption in host1x_reloc_copy_from_user
--
commit 6284447bfe9e49ad17b9df316519006595821f25
Author: Wentao Liang <vulab@iscas.ac.cn>
drm/tegra: Fix bo reference leak in host1x_reloc_copy_from_user()
This commit fixes a reference leak on the command buffer object when the
subsequent lookup for the relocation target fails. It drops the reference
before returning the error.
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 324480c87fb1f..1a70d37b8c1f3 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -159,8 +159,10 @@ static int host1x_reloc_copy_from_user(struct host1x_reloc *dest,
> return -ENOENT;
>
> dest->target.bo = tegra_gem_lookup(file, target);
> - if (!dest->target.bo)
> + if (!dest->target.bo) {
> + drm_gem_object_put(dest->cmdbuf.bo);
[Severity: High]
Does this cause memory corruption due to a type mismatch?
Looking at host1x_reloc_copy_from_user(), dest->cmdbuf.bo is a struct
host1x_bo pointer. Passing it to drm_gem_object_put(), which expects a
struct drm_gem_object pointer, appears to lead to type confusion.
When tegra_gem_lookup(file, target) fails and this error path is taken,
drm_gem_object_put() will attempt to decrement the reference count by
treating the struct host1x_bo as a struct drm_gem_object. This is likely
to decrement the first member of struct host1x_bo, which is its ops vtable
pointer, instead of an actual kref.
Since this is reachable from userspace via the DRM_IOCTL_TEGRA_SUBMIT ioctl
by supplying a valid cmdbuf but an invalid target BO, could this corrupt
the vtable pointer and lead to crashes or potential control-flow hijacking
when the ops are later used?
> return -ENOENT;
> + }
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260916182550.2091797-1-vulab@iscas.ac.cn?part=1
next prev parent reply other threads:[~2026-09-16 18:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 18:25 [PATCH] drm/tegra: Fix bo reference leak in host1x_reloc_copy_from_user() Wentao Liang
2026-09-16 18:37 ` sashiko-bot [this message]
2026-09-17 7:35 ` kernel test robot
2026-09-17 8:41 ` kernel test robot
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=20260916183724.5ED331F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vulab@iscas.ac.cn \
/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.