Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] gpu: nova-core: missing validation of GSP element_count causes DoS or queue corruption --
commit 4735296acba7b78deac091e3d6a7e814d360afff Author: Alexandre Courbot <[email protected]> gpu: nova-core: gsp: cmdq: use element_count to advance queue pointer This commit changes the command queue message receiving logic to use the element_count from the transport-level header instead of recalculating the slot count from the message length. > diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs > b/drivers/gpu/nova-core/gsp/cmdq.rs > index a5595da23407b..9285fd796f9d3 100644 > --- a/drivers/gpu/nova-core/gsp/cmdq.rs > +++ b/drivers/gpu/nova-core/gsp/cmdq.rs > @@ -863,9 +863,8 @@ fn receive_msg<M: MessageFromGsp>(&mut self, timeout: > Delta) -> Result<M> > }; > > // Advance the read pointer past this message. > - self.gsp_mem.advance_cpu_read_ptr(u32::try_from( > - message.header.length().div_ceil(GSP_PAGE_SIZE), > - )?); > + self.gsp_mem > + .advance_cpu_read_ptr(message.header.element_count()); [Severity: High] Does this leave the driver vulnerable to a compromised or buggy GSP firmware? By directly using the untrusted, DMA-mapped message.header.element_count() to advance the ring buffer read pointer without validation, this could potentially allow the hardware to trigger a denial of service or memory corruption. If the hardware provides an element_count of 0, could it fail to advance the pointer and lead to an infinite retry loop when send_command() is called, causing a host lockup? Conversely, if a maliciously large value is provided, could the read pointer advance past the write pointer, causing the driver to process uninitialized memory as legitimate messages? Should this value be validated against the available read area bounds before being passed to advance_cpu_read_ptr()? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
