Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Firmware structures are parsed using native integer types, causing endianness mismatches on big-endian architectures. -- commit f0a0d5143a0bf185e80fec9d804b5bc8f1e3c0b1 Author: Pedro Yudi Honda <[email protected]> drm/nova: use zerocopy in booter.rs This commit replaces the transmute::FromBytes traits with their zerocopy::FromBytes equivalents in the firmware/booter.rs file. It updates the call sites and struct derivations to match the new library usage. > diff --git a/drivers/gpu/nova-core/firmware/booter.rs > b/drivers/gpu/nova-core/firmware/booter.rs > index d9313ac361af3..0cda2c50fbbe9 100644 > --- a/drivers/gpu/nova-core/firmware/booter.rs > +++ b/drivers/gpu/nova-core/firmware/booter.rs [ ... ] > @@ -44,7 +43,7 @@ fn frombytes_at<S: FromBytes + Sized>(slice: &[u8], offset: > usize) -> Result<S> > let end = offset.checked_add(size_of::<S>()).ok_or(EINVAL)?; > slice > .get(offset..end) > - .and_then(S::from_bytes_copy) > + .and_then(|b| S::read_from_bytes(b).ok()) > .ok_or(EINVAL) > } > > @@ -53,7 +52,7 @@ fn frombytes_at<S: FromBytes + Sized>(slice: &[u8], offset: > usize) -> Result<S> > /// Such firmwares have an application-specific payload that needs to be > patched with a given > /// signature. > #[repr(C)] > -#[derive(Debug, Clone)] > +#[derive(Debug, Clone, FromBytes)] > struct HsHeaderV2 { > /// Offset to the start of the signatures. > sig_prod_offset: u32, > /// Size of the signatures. > sig_prod_size: u32, [Severity: High] This is a pre-existing issue, but does using native integer types like u32 in firmware structures cause endianness mismatches on big-endian architectures? When frombytes_at() reads the firmware headers directly from fixed-endian firmware blobs into host-endian structures using S::read_from_bytes(b), the driver will parse incorrect offset and size values on big-endian systems. Should these structures be updated to use explicitly endian-aware types (like kernel::types::Le32) for fields such as sig_prod_offset and sig_prod_size to ensure correct parsing across all architectures and avoid potential out-of-bounds memory accesses? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3
