linux-kernel - Re: [PATCH] scsi: NCR5380: Prevent potential out-of-bounds read in spi_print

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9028680b0d2b7c42d0e990bbdcd247d824e01153.camel@HansenPartnership.com>
Date: Wed, 30 Apr 2025 08:59:36 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Rand Deeb <rand.sec96@...il.com>, Finn Thain <fthain@...ux-m68k.org>, 
 Michael Schmitz <schmitzmic@...il.com>, "Martin K. Petersen"
 <martin.petersen@...cle.com>, "open list:NCR 5380 SCSI DRIVERS"
 <linux-scsi@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Cc: deeb.rand@...fident.ru, lvc-project@...uxtesting.org, 
	voskresenski.stanislav@...fident.ru
Subject: Re: [PATCH] scsi: NCR5380: Prevent potential out-of-bounds read in
 spi_print_msg()

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