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