[PATCH] drm/tyr: gpu_info: zero out new/unused fields

[PATCH] drm/tyr: gpu_info: zero out new/unused fields

[Deborah Brouwer]

If a new field is added to the struct drm_panthor_gpu_info in the panthor
uapi, Tyr must initialize this field or it will cause a compile error.

To pre-emptively avoid compile errors, use ..pin_init::zeroed() to zero
out all new fields added to this struct. Tyr can subsequently change the
initialization as necessary. Also use it instead of manually zeroing out
existing fields at the end of the struct.

Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
---
 drivers/gpu/drm/tyr/gpu.rs | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tyr/gpu.rs b/drivers/gpu/drm/tyr/gpu.rs
index 592b8bb16eba..e1b04a0c5159 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()
         })
     }
 

---
base-commit: e1a9f41b896f0d57eb1165dd8a4c7446be6af638
change-id: 20260922-b4-gpu_info_zero-f7ce6ee69a89

Best regards,
-- 
Deborah Brouwer <deborah.brouwer@collabora.com>

Re: [PATCH] drm/tyr: gpu_info: zero out new/unused fields

[sashiko-bot]

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

Re: [PATCH] drm/tyr: gpu_info: zero out new/unused fields

[Alice Ryhl]

On Wed, Sep 23, 2026 at 1:16 AM Deborah Brouwer
<deborah.brouwer@collabora.com> wrote:
>
> If a new field is added to the struct drm_panthor_gpu_info in the panthor
> uapi, Tyr must initialize this field or it will cause a compile error.
>
> To pre-emptively avoid compile errors, use ..pin_init::zeroed() to zero
> out all new fields added to this struct. Tyr can subsequently change the
> initialization as necessary. Also use it instead of manually zeroing out
> existing fields at the end of the struct.
>
> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>

Merged into drm-rust-next, thanks!

With regards to sashiko bot, we should look into whether the
MaybeZeroable that bindgen adds to structs applies on this struct. If
so, we can remove our unsafe impl block. But it's not an issue in this
patch.

Alice

Re: [PATCH] drm/tyr: gpu_info: zero out new/unused fields

[Deborah Brouwer]

On Wed, Sep 23, 2026 at 09:42:23AM +0200, Alice Ryhl wrote:
> On Wed, Sep 23, 2026 at 1:16 AM Deborah Brouwer
> <deborah.brouwer@collabora.com> wrote:
> >
> > If a new field is added to the struct drm_panthor_gpu_info in the panthor
> > uapi, Tyr must initialize this field or it will cause a compile error.
> >
> > To pre-emptively avoid compile errors, use ..pin_init::zeroed() to zero
> > out all new fields added to this struct. Tyr can subsequently change the
> > initialization as necessary. Also use it instead of manually zeroing out
> > existing fields at the end of the struct.
> >
> > Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> 
> Merged into drm-rust-next, thanks!
> 
> With regards to sashiko bot, we should look into whether the
> MaybeZeroable that bindgen adds to structs applies on this struct. If
> so, we can remove our unsafe impl block. But it's not an issue in this
> patch.

I couldn't use MaybeZeroable directly but if I add IntoBytes and
Immutable then we can stop implementing unsafe trait AsBytes. Could you
please review:

https://lore.kernel.org/rust-for-linux/20260923-b4-gpu_info_intobytes-v1-1-bb2173f91e11@collabora.com/


> 
> Alice

Re: [PATCH] drm/tyr: gpu_info: zero out new/unused fields

[Alice Ryhl]

On Thu, Sep 24, 2026 at 2:27 AM Deborah Brouwer
<deborah.brouwer@collabora.com> wrote:
>
> On Wed, Sep 23, 2026 at 09:42:23AM +0200, Alice Ryhl wrote:
> > On Wed, Sep 23, 2026 at 1:16 AM Deborah Brouwer
> > <deborah.brouwer@collabora.com> wrote:
> > >
> > > If a new field is added to the struct drm_panthor_gpu_info in the panthor
> > > uapi, Tyr must initialize this field or it will cause a compile error.
> > >
> > > To pre-emptively avoid compile errors, use ..pin_init::zeroed() to zero
> > > out all new fields added to this struct. Tyr can subsequently change the
> > > initialization as necessary. Also use it instead of manually zeroing out
> > > existing fields at the end of the struct.
> > >
> > > Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
> >
> > Merged into drm-rust-next, thanks!
> >
> > With regards to sashiko bot, we should look into whether the
> > MaybeZeroable that bindgen adds to structs applies on this struct. If
> > so, we can remove our unsafe impl block. But it's not an issue in this
> > patch.
>
> I couldn't use MaybeZeroable directly but if I add IntoBytes and
> Immutable then we can stop implementing unsafe trait AsBytes. Could you
> please review:
>
> https://lore.kernel.org/rust-for-linux/20260923-b4-gpu_info_intobytes-v1-1-bb2173f91e11@collabora.com/

Oh, yeah, MaybeZeroable isn't the one we want. We'd want MaybeAsBytes,
but I'm not sure that exists yet. I think we asked for it, but not
sure the state.

Alice