Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Kernel panic due to `chunks_exact(0)` when parsing malformed firmware signatures. -- commit d903748e1752198088438b960539204b5710d605 Author: Pedro Yudi Honda <[email protected]> drm/nova: use `zerocopy` in booter.rs In firmware/booter.rs, replace the following `transmute` traits with their `zerocopy` equivalents: - `transmute::FromBytes` -> `zerocopy::FromBytes` Update call sites accordingly. > diff --git a/drivers/gpu/nova-core/firmware/booter.rs > b/drivers/gpu/nova-core/firmware/booter.rs > index acb7f4d8a5327..fe9389b84b90a 100644 > --- a/drivers/gpu/nova-core/firmware/booter.rs > +++ b/drivers/gpu/nova-core/firmware/booter.rs [ ... ] > @@ -144,6 +140,7 @@ fn signatures_iter(&'a self) -> Result<impl Iterator<Item > = BooterSignature<'a>> [Severity: High] This isn't a bug introduced by this patch, but I noticed a pre-existing issue in signatures_iter(). If a malformed firmware file provides a num_sig greater than sig_prod_size (but not 0), sig_size will evaluate to 0 because integer division truncates towards zero. Calling chunks_exact() with a chunk size of 0 triggers a kernel panic: drivers/gpu/nova-core/firmware/booter.rs:signatures_iter() { ... self.fw // Get signatures range. .get(signatures_start..signatures_end) .ok_or(EINVAL)? .chunks_exact(sig_size.into_safe_cast()) ... } Could this allow a local user who controls the firmware image or triggers its loading to crash the kernel? > > /// Signature parameters, as defined in the firmware. > #[repr(C)] > +#[derive(FromBytes)] > struct HsSignatureParams { > /// Fuse version to use. > fuse_ver: u32, -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
