We're possibly losing information by shifting an int.
Fix it by adding the necessary cast.
Found by OMP on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Karina Yankevich <[email protected]>
---
drivers/usb/storage/sddr55.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/sddr55.c b/drivers/usb/storage/sddr55.c
index 15dc25801cdc..4aeff73de147 100644
--- a/drivers/usb/storage/sddr55.c
+++ b/drivers/usb/storage/sddr55.c
@@ -236,7 +236,7 @@ static int sddr55_read_data(struct us_data *us,
memset (buffer, 0, len);
} else {
- address = (pba << info->blockshift) + page;
+ address = ((unsigned long)pba << info->blockshift) + page;
command[0] = 0;
command[1] = LSB_of(address>>16);
@@ -411,7 +411,7 @@ static int sddr55_write_data(struct us_data *us,
command[4] = 0x40;
}
- address = (pba << info->blockshift) + page;
+ address = ((unsigned long)pba << info->blockshift) + page;
command[1] = LSB_of(address>>16);
command[2] = LSB_of(address>>8);
--
2.39.1
On Fri, Feb 03, 2023 at 11:18:21PM +0300, Karina Yankevich wrote:
> We're possibly losing information by shifting an int.
> Fix it by adding the necessary cast.
Nonsense. The card's _total_ capacity is no larger than 128 MB, so a
page address can't possibly overflow an int.
Alan Stern
> Found by OMP on behalf of Linux Verification Center
> (linuxtesting.org) with SVACE.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Karina Yankevich <[email protected]>
> ---
> drivers/usb/storage/sddr55.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/storage/sddr55.c b/drivers/usb/storage/sddr55.c
> index 15dc25801cdc..4aeff73de147 100644
> --- a/drivers/usb/storage/sddr55.c
> +++ b/drivers/usb/storage/sddr55.c
> @@ -236,7 +236,7 @@ static int sddr55_read_data(struct us_data *us,
> memset (buffer, 0, len);
> } else {
>
> - address = (pba << info->blockshift) + page;
> + address = ((unsigned long)pba << info->blockshift) + page;
>
> command[0] = 0;
> command[1] = LSB_of(address>>16);
> @@ -411,7 +411,7 @@ static int sddr55_write_data(struct us_data *us,
> command[4] = 0x40;
> }
>
> - address = (pba << info->blockshift) + page;
> + address = ((unsigned long)pba << info->blockshift) + page;
>
> command[1] = LSB_of(address>>16);
> command[2] = LSB_of(address>>8);
> --
> 2.39.1
>
Hello!
On 2/3/23 11:48 PM, Alan Stern wrote:
[...]
>> We're possibly losing information by shifting an int.
>> Fix it by adding the necessary cast.
>
> Nonsense. The card's _total_ capacity is no larger than 128 MB, so a
> page address can't possibly overflow an int.
Then the 'address' variables shouldn't be declared *unsigned long*, right?
That should fix the SVACE's report as well. Would you accept such a patch?
> Alan Stern
[...]
MBR, Sergey
On Mon, Feb 06, 2023 at 11:04:54PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 2/3/23 11:48 PM, Alan Stern wrote:
> [...]
> >> We're possibly losing information by shifting an int.
> >> Fix it by adding the necessary cast.
> >
> > Nonsense. The card's _total_ capacity is no larger than 128 MB, so a
> > page address can't possibly overflow an int.
>
> Then the 'address' variables shouldn't be declared *unsigned long*, right?
> That should fix the SVACE's report as well. Would you accept such a patch?
Yes.
Alan Stern
SVACE static analyzer complains that we're possibly
losing information by shifting an 'unsigned int pba'
variables in sddr55_{read,write}_data().
It is a false positive, because of the card's total capacity
is no larger than 128 MB. But 'unsigned int' is more
suitable in this case.
Found by OMP on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Karina Yankevich <[email protected]>
---
drivers/usb/storage/sddr55.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/sddr55.c b/drivers/usb/storage/sddr55.c
index 15dc25801cdc..0aa079405d23 100644
--- a/drivers/usb/storage/sddr55.c
+++ b/drivers/usb/storage/sddr55.c
@@ -196,7 +196,7 @@ static int sddr55_read_data(struct us_data *us,
unsigned char *buffer;
unsigned int pba;
- unsigned long address;
+ unsigned int address;
unsigned short pages;
unsigned int len, offset;
@@ -316,7 +316,7 @@ static int sddr55_write_data(struct us_data *us,
unsigned int pba;
unsigned int new_pba;
- unsigned long address;
+ unsigned int address;
unsigned short pages;
int i;
--
2.39.1
On Mon, Feb 27, 2023 at 02:25:41PM +0300, Karina Yankevich wrote:
> SVACE static analyzer complains that we're possibly
> losing information by shifting an 'unsigned int pba'
> variables in sddr55_{read,write}_data().
> It is a false positive, because of the card's total capacity
> is no larger than 128 MB. But 'unsigned int' is more
> suitable in this case.
Please wrap at 72 columns.
> Found by OMP on behalf of Linux Verification Center
> (linuxtesting.org) with SVACE.
What is "OMP"?
What is "SVACE"?
And why change anything if there is not a real issue?
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
That's obviously not the correct commit id for such a "fix" as this is
not a real issue.
thanks,
greg k-h
Hello!
Sorry for the really long delay! Your reply scared off Karina
(it was her 1st kernel patch), so I'm trying to pick this patch up
where it was left back in February...
On 2/27/23 2:54 PM, Greg Kroah-Hartman wrote:
[...]
>> SVACE static analyzer complains that we're possibly
>> losing information by shifting an 'unsigned int pba'
>> variables in sddr55_{read,write}_data().
>> It is a false positive, because of the card's total capacity
>> is no larger than 128 MB. But 'unsigned int' is more
>> suitable in this case.
>
> Please wrap at 72 columns.
>
>> Found by OMP on behalf of Linux Verification Center
>> (linuxtesting.org) with SVACE.
>
> What is "OMP"?
Open Mobile Platform, LLC. The website is in Russian only:
https://www.omp.ru
> What is "SVACE"?
The patch description said thst it's a static analyzer.
Here's the link to the Institute for System Programming web page about it:
https://www.ispras.ru/en/technologies/svace/
> And why change anything if there is not a real issue?
We needlessly use 64-bit type on 64-bit arches.
>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> That's obviously not the correct commit id for such a "fix" as this is
> not a real issue.
That's correct. We'll remove this tag.
> thanks,
>
> greg k-h
MBR, Srrgey
On Fri, Dec 01, 2023 at 07:16:56PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Sorry for the really long delay! Your reply scared off Karina
> (it was her 1st kernel patch), so I'm trying to pick this patch up
> where it was left back in February...
Note, any submitter should be able to answer questions about their
change, as remember, if I take it I am now responsible for it. If they
do not want to respond that means they do not want to be responsible for
it, which of course means we can't accept it :(
thanks,
greg k-h