Re: [PATCH 1/2] scsi: bsg: fix TOCTOU in io_uring passthrough command setup
Caleb Sander Mateos <[email protected]> Thu, 23 Jul 2026 18:10:27 -0700
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-scsi,org.kernel.vger.stable |
|---|---|
| Message-ID | <CADUfDZpsTH7zU4gyVE11R9GxdadjbcrcGVX+btoEjRYS-tBiGQ@mail.gmail.com> |
On Thu, Jul 23, 2026 at 5:50 PM Yang Xiuwei <[email protected]> wrote: > > Hi Caleb, > > On Thu, Jul 23, 2026 at 09:56:08AM -0700, Caleb Sander Mateos wrote: > > cmd->max_response_len is passed through here, shouldn't it be accessed > > using READ_ONCE() too? Omitting READ_ONCE() only seems safe for values > > that are ignored (except for a possible check that they match a fixed > > value). > > > > Ditto for cmd->timeout_ms later in this function. > > timeout_ms is the example Jens already called out as not mattering if > userspace rewrites the SQE: > > https://lore.kernel.org/r/[email protected] > > max_response_len is similar here: we clamp with > min(..., SCSI_SENSE_BUFFERSIZE), so it cannot overflow the sense > buffer. Same idea for response. I don't think that's true. Without READ_ONCE(), the compiler can assume no other thread will concurrently write cmd->max_response_len (else it would be UB). So it's allowed to load it multiple times: cmd->max_response_len ? min(cmd->max_response_len, SCSI_SENSE_BUFFERSIZE) : SCSI_SENSE_BUFFERSIZE becomes cmd->max_response_len ? (cmd->max_response_len < SCSI_SENSE_BUFFERSIZE ? cmd->max_response_len : SCSI_SENSE_BUFFERSIZE) : SCSI_SENSE_BUFFERSIZE And if cmd->max_response_len changes between the second and third loads, this could definitely evaluate to a value greater than SCSI_SENSE_BUFFERSIZE. Best, Caleb