* Re: How to fix problems with the sashiko review model
[not found] ` <dcadf40a07a616de931c484bbe68f4b3f1f83b80.camel@HansenPartnership.com>
@ 2026-07-22 12:11 ` Laurent Pinchart
2026-07-22 12:42 ` James Bottomley
0 siblings, 1 reply; 2+ messages in thread
From: Laurent Pinchart @ 2026-07-22 12:11 UTC (permalink / raw)
To: James Bottomley
Cc: sashiko-reviews, Chris Mason, Roman Gushchin, linux-scsi, ksummit,
workflows
On Wed, Jul 22, 2026 at 07:58:48AM -0400, James Bottomley wrote:
> There doesn't seem to be a Sashiko list, so I added ksummit as the most
> likely one to catch attention. We got this review in SCSI on this
> thread:
workflows@vger.kernel.org seems a good candidate for discussions about
tooling. The mailing list was created to share workflows and tools
between maintainers as far as I understand.
> https://lore.kernel.org/linux-scsi/20260722041257.1557-1-pengpeng@iscas.ac.cn/
>
> But this part of the review
>
> On Wed, 2026-07-22 at 04:27 +0000, sashiko-bot@kernel.org wrote:
> [...]
> > > +
> > > + reply_len = mpi_reply->MsgLength * 4;
> > > + if (reply_len < event_offset || reply_len > ioc->reply_sz)
> > > + return false;
> > > +
> > > + event_data_len = le16_to_cpu(mpi_reply->EventDataLength) *
> > > 4;
> >
> > [Severity: High]
> > Is there a Time-of-Check to Time-of-Use window here since mpi_reply
> > is read directly from shared DMA memory?
> >
> > The validation function reads bounds from mpi_reply, but after
> > validation passes, mpt3sas_scsih_event_callback() re-reads fields
> > like EventDataLength and NumEntries directly from the same DMA-backed
> > memory.
> >
> > Could a malicious device mutate these fields in the window between
> > validation and use to bypass the checks introduced by this patch?
>
> Is wrong. Hardware may never be presumed to be malicious (well, except
> if it's virtual hardware provided by an untrusted host to a
> confidential guest, but that's a very small list of drivers or it's a
> USB or thunderbolt device designed to attack or exfiltrate data from an
> unattended system). It may be buggy, but we never presume bugs until
> someone finds a device exhibiting the bug in the field (so we don't
> proactively fix them).
>
> The bigger part of this is that I was looking into how to fix this
> (which might interest a broader swathe of developers than just SCSI).
> I think the fault is in the review prompts:
>
> https://github.com/masoncl/review-prompts
>
> And what I need to do is to add an additional drivers.md file to
> kernel/subsystems explaining this? If that's right I can send a pull
> request, but I thought I'd check here because the audience is much
> bigger than if it were to get discussed in the github PR.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 2+ messages in thread