From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Rand Deeb <rand.sec96@gmail.com>,
Finn Thain <fthain@linux-m68k.org>,
Michael Schmitz <schmitzmic@gmail.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"open list:NCR 5380 SCSI DRIVERS" <linux-scsi@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Cc: deeb.rand@confident.ru, lvc-project@linuxtesting.org,
voskresenski.stanislav@confident.ru
Subject: Re: [PATCH] scsi: NCR5380: Prevent potential out-of-bounds read in spi_print_msg()
Date: Wed, 30 Apr 2025 08:59:36 -0400 [thread overview]
Message-ID: <9028680b0d2b7c42d0e990bbdcd247d824e01153.camel@HansenPartnership.com> (raw)
In-Reply-To: <20250430115926.6335-1-rand.sec96@gmail.com>
On Wed, 2025-04-30 at 14:59 +0300, Rand Deeb wrote:
> spi_print_msg() assumes that the input buffer is large enough to
> contain the full SCSI message, including extended messages which may
> access msg[2], msg[3], msg[7], and beyond based on message type.
That's true because it's a generic function designed to work for all
parallel card. However, this card only a narrow non-HVD low frequency
one, so it only really speaks a tiny subset of this (in particular it
would never speak messages over 3 bytes).
> NCR5380_reselect() currently allocates a 3-byte buffer for 'msg'
> and reads only a single byte from the SCSI bus before passing it to
> spi_print_msg(), which can result in a potential out-of-bounds read
> if the message is malformed or declares a longer length.
The reselect protocol *requires* the next message to be an identify.
Since these cards and the devices they attack to are all decades old, I
think if they were going to behave like this we'd have seen it by now.
The bottom line is we don't add this type of thing to a device facing
interface unless there's evidence of an actual negotiation problem.
[...]
> @@ -2084,7 +2084,7 @@ static void NCR5380_reselect(struct Scsi_Host
> *instance)
> msg[0] = NCR5380_read(CURRENT_SCSI_DATA_REG);
> #else
> {
> - int len = 1;
> + int len = sizeof(msg);
You didn't test this, did you? The above code instructs the card to
wait for 16 bytes on reselection and abort if they aren't found ...
i.e. every reselection now aborts because the device is only sending a
one byte message.
Regards,
James
next prev parent reply other threads:[~2025-04-30 12:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-30 11:59 Rand Deeb
2025-04-30 12:59 ` James Bottomley [this message]
2025-05-05 5:00 ` Rand Deeb
2025-05-01 3:40 ` Finn Thain
2025-05-07 7:31 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9028680b0d2b7c42d0e990bbdcd247d824e01153.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=deeb.rand@confident.ru \
--cc=fthain@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=martin.petersen@oracle.com \
--cc=rand.sec96@gmail.com \
--cc=schmitzmic@gmail.com \
--cc=voskresenski.stanislav@confident.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome