linux-kernel - Re: [PATCH 26/44] drivers/scsi: use min() instead of min

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251122215023.2fe10a2b@pumpkin>
Date: Sat, 22 Nov 2025 21:50:23 +0000
From: David Laight <david.laight.linux@...il.com>
To: Bart Van Assche <bvanassche@....org>
Cc: linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org, "James E.J.
 Bottomley" <James.Bottomley@...senPartnership.com>, "Martin K. Petersen"
 <martin.petersen@...cle.com>
Subject: Re: [PATCH 26/44] drivers/scsi: use min() instead of min_t()

On Wed, 19 Nov 2025 15:09:02 -0800
Bart Van Assche <bvanassche@....org> wrote:

> On 11/19/25 2:41 PM, david.laight.linux@...il.com wrote:
> > From: David Laight <david.laight.linux@...il.com>
> > 
> > min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'.
> > Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long'
> > and so cannot discard significant bits.
> > 
> > In this case the 'unsigned long' value is small enough that the result
> > is ok.
> > 
> > Detected by an extra check added to min_t().
> > 
> > Signed-off-by: David Laight <david.laight.linux@...il.com>
> > ---
> >   drivers/scsi/hosts.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> > index 17173239301e..b15896560cf6 100644
> > --- a/drivers/scsi/hosts.c
> > +++ b/drivers/scsi/hosts.c
> > @@ -247,7 +247,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct device *dev,
> >   	shost->dma_dev = dma_dev;
> >   
> >   	if (dma_dev->dma_mask) {
> > -		shost->max_sectors = min_t(unsigned int, shost->max_sectors,
> > +		shost->max_sectors = min(shost->max_sectors,
> >   				dma_max_mapping_size(dma_dev) >> SECTOR_SHIFT);
> >   	}  
> 
> So instead of the type cast performed by min_t() potentially discarding
> bits, the assignment potentially discards bits. I'm not sure this is an
> improvement.

In this case the assignment is fine - shost->max_sectors is on both sides,
so the value can only go down.

The issue is that dma_max_mapping_size() returns a 64bit value.
So if you have some magic high speed interface with a 2TB 'dma map'
then 'dma_max_mapping_size(dma_dev) >> SECTOR_SHIFT' is '1u << 32' so
is zero when cast to 'unsigned int'.
At that point things start going horribly wrong.

I don't think there are any such interfaces - so the bug this fixes
can't happen.

OTOH the same test does pick up a lot (and I mean a lot [1]) of driver code
that contains code like:
ssize_t do_xxx(...  size_t len)
{
	unsigned int copied = 0, frag_len;
	while (copied < len) {
		frag_len = min_t(unsigned int, len, MAX_FRAG);
		....
		copied += frag_len;
		len -= frag_len;
	}
	return copied;
}

If you manage to request a transfer for 4G (or more) then it doesn't work.
Now there might be a test earlier that stops that happening in a lot of places.
But from the perspective of the function it isn't true.
(I suspect readv() with a single iov[] can generate a big buffer.)
The compile-time test detects that (unsigned int)len may not equal len
and it can be fixed by changing to min(len, MAX_FRAG);
In this case it might be a real bug.

Note that a read can be truncated after a few bytes - it is only the
buffer size that needs to be massive.

	David

[1] I've just built allmodconfig - 'only' 488 more files needed changing.
A fair number of 'real bugs', a few false positives because PAGE_SIZE and
sizeof() are 64bit, and a lot of dubious code.
By far the worst are all the min_t([u8|u16], ...) in many cases the code
uses the type of the destination - so you get (eg):
	u8_var = min(u8, value_32 / 2, 255);

> 
> Thanks,
> 
> Bart.