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 <[email protected]> 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/[email protected]?part=1
