Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] gpu/nova: GSP message queue permanently wedges due to untruncated checksum calculation --
commit 5dd9973126ada78a1c8fff2d08bacb19190898fd Author: Alexandre Courbot <[email protected]> gpu: nova-core: gsp: cmdq: validate checksum earlier on receive This commit moves the checksum validation of received messages to occur before the RPC message header is accessed. > diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs > b/drivers/gpu/nova-core/gsp/cmdq.rs > index 9285fd796f9d3..08a49450bca0f 100644 > --- a/drivers/gpu/nova-core/gsp/cmdq.rs > +++ b/drivers/gpu/nova-core/gsp/cmdq.rs > @@ -768,6 +768,17 @@ fn wait_for_msg(&self, timeout: Delta) -> > Result<GspMessage<'_>> { > // Extract the `GspMsgElement`. > let (header, slice_1) = > GspMsgElement::from_bytes_prefix(slice_1).ok_or(EIO)?; > > + // Validate checksum. > + if Cmdq::calculate_checksum(SBufferIter::new_reader([ > + header.as_bytes(), > + slice_1, > + slice_2, > + ])) != 0 > + { [Severity: High] Does this perform the checksum validation on slice_1 and slice_2 before they have been truncated to the actual message length? If the read area spans more bytes than the actual message length, could the slices contain non-zero trailing data from subsequent messages or old uninitialized data in the circular buffer page? If the checksum is calculated over the entire un-truncated read area, wait_for_msg() will return Err(EIO) without advancing the read pointer. Could this cause the GSP message queue to wedge permanently, as subsequent calls will repeatedly read the exact same bytes and fail the checksum again? > + dev_err!(&self.dev, "GSP receive: bad checksum\n"); > + return Err(EIO); > + } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
