From: sashiko-bot@kernel.org
To: "Deborah Brouwer" <deborah.brouwer@collabora.com>
Cc: dri-devel@lists.freedesktop.org, ojeda@kernel.org, gary@garyguo.net
Subject: Re: [PATCH] drm/tyr: gpu_info: zero out new/unused fields
Date: Tue, 22 Sep 2026 23:26:40 +0000 [thread overview]
Message-ID: <20260922232641.2676E1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922-b4-gpu_info_zero-v1-1-7259840069c6@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tyr: potential info leak via struct update syntax on AsBytes type
--
commit d7b094df57d808ec86e2a433719f13280d288430
Author: Deborah Brouwer <deborah.brouwer@collabora.com>
drm/tyr: gpu_info: zero out new/unused fields
This commit updates the initialization of the UAPI struct drm_panthor_gpu_info
to use ..pin_init::zeroed(). This is intended to pre-emptively avoid compile
errors when new fields are added to the UAPI definition.
> diff --git a/drivers/gpu/drm/tyr/gpu.rs b/drivers/gpu/drm/tyr/gpu.rs
> index 592b8bb16eba1..e1b04a0c5159b 100644
> --- a/drivers/gpu/drm/tyr/gpu.rs
> +++ b/drivers/gpu/drm/tyr/gpu.rs
> @@ -74,10 +74,8 @@ pub(crate) fn new(io: &IoMem<'_>) -> Self {
> io.read(TILER_PRESENT_HI).into_raw(),
> ),
> core_features: io.read(CORE_FEATURES).into_raw(),
> - // Padding must be zero.
> - pad: 0,
> - //GPU_FEATURES register is not available; it was introduced in arch 11.x.
> - gpu_features: 0,
> + // Zero unsupported and newly added UAPI fields.
> + ..pin_init::zeroed()
[Severity: Medium]
Could this struct update syntax accidentally leak kernel stack memory to
userspace if padding is introduced in a future UAPI update?
While pin_init::zeroed() produces a fully zeroed struct, the struct update
syntax (..base) creates a new instance by copying explicit fields from the
base and leaves any implicit padding bytes uninitialized.
Since GpuInfo manually implements AsBytes to allow byte-for-byte copies to
userspace, and this patch suppresses missing-field compile errors, any
future UAPI change that introduces implicit padding might be silently
accepted by the compiler. That padding would remain uninitialized on the
stack and be leaked to userspace.
Would it be safer to fully zero the struct before mutation, like this?
let mut info: uapi::drm_panthor_gpu_info = pin_init::zeroed();
info.gpu_id = ...;
Self(info)
> })
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-b4-gpu_info_zero-v1-1-7259840069c6@collabora.com?part=1
next prev parent reply other threads:[~2026-09-22 23:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 23:16 [PATCH] drm/tyr: gpu_info: zero out new/unused fields Deborah Brouwer
2026-09-22 23:26 ` sashiko-bot [this message]
2026-09-23 7:42 ` Alice Ryhl
2026-09-24 0:27 ` Deborah Brouwer
2026-09-24 7:11 ` Alice Ryhl
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=20260922232641.2676E1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=deborah.brouwer@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=ojeda@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox